Distributed Storage System Data Management And Security

ABSTRACT

A system and method for distributing data over a plurality of remote storage nodes. Data are split into segments and each segment is encoded into a number of codeword chunks. None of the codeword chunks contains any of the segments. Each codeword chunk is packaged with at least one encoding parameter and identifier, and metadata are generated for at least one file and for related segments of the at least one file. The metadata contains information to reconstruct from the segments, and information for reconstructing from corresponding packages. Further, metadata are encoded into package(s), and correspond to a respective security level and a protection against storage node failure. A plurality of packages are assigned to remote storage nodes to optimize workload distribution. Each package is transmitted to at least one respective storage node as a function iteratively accessing and retrieving the packages of metadata and file data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. Non-Provisional patentapplication Ser. No. 15/460,093, filed Mar. 15, 2017, which is based onand claims priority to: U.S. Provisional Patent Application No.62/308,223, filed Mar. 15, 2016; U.S. Provisional Patent Application No.62/332,002, filed May 5, 2016; U.S. Provisional Patent Application No.62/349,145, filed Jun. 13, 2016; and U.S. Provisional Patent ApplicationNo. 62/434,421, filed Dec. 15, 2016, the entire contents of each whichis incorporated by reference as if expressly set forth in its respectiveentirety herein. This application further incorporates by reference U.S.Non-Provisional patent application Ser. No. 15/304,457, filed Oct. 14,2016 as if expressly set forth in its entirety herein.

FIELD OF THE APPLICATION

The application described herein, generally, relates to distributedstorage system and, more particularly, to techniques for data protectionagainst failures in distributed storage systems.

BACKGROUND OF THE APPLICATION

Distributed storage systems play an important role in management of bigdata, particularly for data generated at tremendous speed. A distributedstorage system may require many hardware devices, which often results incomponent failures that require recovery operations. Moreover,components in a distributed storage system may become unavailable, suchas due to poor network connectivity or performance, without necessarilycompletely failing. In view that any individual storage node may becomeunreliable, redundancy measures are often introduced to protect dataagainst storage node failures and outages, or other impediments. Suchmeasures can include distributing data with redundancy over a set ofindependent storage nodes.

One relatively simple redundancy measure is replication. Replication,particularly triple replication, is often used in distributed storagesystems to provide fast access to data. Triple replication, however, cansuffer from very low storage efficiency which, as used herein, generallyrefers to a ratio of an amount of original data to an amount of actuallystored data, i.e., data with redundancy. Error-correcting coding, andmore particularly erasure coding, provides an opportunity to store datawith a relatively high storage efficiency, while simultaneouslymaintaining an acceptable level of tolerance against storage nodefailure. Thus, a relatively high storage efficiency can be achieved bymaximum distance separable (MDS) codes, such as, but not limited to,Reed-Solomon codes. Long MDS codes, however, can incur prohibitivelyhigh repair costs. In case of employing locally decodable codes, forexample, any single storage node failure can be recovered by accessing apre-defined number of storage nodes and by performing correspondingcomputations. Locally decodable codes (LDC) are designed to minimize I/Ooverhead. In the case of cloud storage systems, minimization of I/Ooverhead is especially desirable because data transmission can consumemany resources, while computational complexity is less significant. Inspite of promising theoretical results, the number of practicalconstructions of LDC codes is low. It is recognized by the inventorsthat some generalized concatenated codes (GCC) demonstrate a property oflocality. Yet another important consideration regards bandwidthoptimization, which leads to reduced latency. Regenerating codes can beused to reduce the amount of data transmitted during repair from eachstorage node. One drawback, however, is that advantages provided byregenerated codes are limited to partial read operations within storagesystem.

It is observed that requirements of error-correcting code in redundantarrays of independent disks (RAID) can be different, such as in view ofcomputational complexity and storage efficiency. Moreover, the number ofdisks within a RAID is usually limited to a relatively low number,resulting in codes having a relatively small length being employed.Accordingly, array codes such as RDP, EVENODD, are not optimal for cloudstorage systems and distributed storage systems, in general.

Yet another consideration of cloud storage systems is security and, moreparticularly, data encryption. The computation complexity of dataencryption is high, unfortunately, and maintaining keys continues to bean operational issue. Alternative approaches can include mixing originaldata, such that any amount of original data can be reconstructed only byaccessing not less than a pre-defined number of storage nodes. Thispre-defined number of storage nodes is such that probability that amalicious adversary is able to access all these nodes is negligible.

SUMMARY

In one or more implementations, the present application includes asystem and method for distributing data of a plurality of files over aplurality of respective remote storage nodes. This includes splittinginto segments, by at least one processor configured to execute codestored in non-transitory processor readable media, the data of theplurality of files. Each segment is encoded, by the at least oneprocessor, into a number of codeword chunks, wherein none of thecodeword chunks contains any of the segments. Each codeword chunk ispackaged with encoding parameters and identifiers, and the at least oneprocessor generates metadata for at least one file of the plurality offiles and metadata for related segments of the at least one file. themetadata for the at least one file contains information to reconstructthe at least one file from the segments, and metadata for the relatedsegments contains information for reconstructing the related segmentsfrom corresponding packages. Further, the at least one processor encodesthe metadata into at least one package, wherein the encoding correspondsto a respective security level and a protection against storage nodefailure. The at least one processor further assigns a plurality ofpackages to remote storage nodes, wherein the step of assigningcorresponds to optimized workload distribution as a function ofavailable network bandwidth. Each of the package is transmitted to atleast one respective storage node, and at least one of the plurality ofis retrieved files as a function iteratively accessing and retrievingthe packages of metadata and file data.

In one or more implementations, the present application includes thatthe step of splitting into segments provides data within a respectivesegment that comprises a part of one individual file or several files.

In one or more implementations, the present application includesaggregating a plurality of files for a segment as a function ofminimizing a difference between segment size and a total size ofembedded files, and a likelihood of joint retrieval of embedded files.

In one or more implementations, the present application includes thatthe step of encoding each segment includes deduplication as a functionof hash-based features of the file.

In one or more implementations, the present application includes thatthe step of encoding each segment includes encryption, wherein at leastone segment is encrypted entirely with an individual encryption key.

In one or more implementations, the present application includes thatthe encryption key is generated as a function of data being encrypted.

In one or more implementations, the present application includes thateach of a plurality of respective individual encryption keys isencrypted with a respective key encryption key and distributed over arespective storage node, wherein each respective key encryption key isgenerated using a password-based key derivation function.

In one or more implementations, the present application includes thatthe step of encoding each segment includes encryption, wherein at leastone segment is partitioned into pieces, wherein each piece is separatelyencrypted, and further wherein a number of encryption keys per segmentranges from one to the number of pieces.

In one or more implementations, the present application includes thatthe step of encoding each segment comprises erasure coding of mixingdegree S, wherein codeword chunks are produced from information chunksusing a linear block error correction code, and mixing degree S requiresat least S codeword chunks to reconstruct any information chunk.

In one or more implementations, the present application includes thatrespective erasure coding techniques are used for data segment encodingand metadata encoding, such that metadata is protected from at leaststorage node failure.

In one or more implementations, the present application includes thatthe step of assigning packages to remote storage nodes minimizesretrieval latency for a group of related segments.

In one or more implementations, the present application includes thatthe retrieval latency is minimized as a function of at least statisticaldata used to compute availability coefficients for storage nodes,wherein an availability coefficient characterizes predicted averagedownload speed for a respective storage node.

In one or more implementations, the present application includes thatretrieval latency is minimized as a function of at least availabilitycoefficients for storage nodes and relevance coefficients for codewordpositions.

In one or more implementations, the present application includes that arelevance coefficient is a function of information representing anemployed erasure correction coding scheme and significance of therespective codeword position for data retrieval.

In one or more implementations, the present application includes thatmetadata for a file and metadata for related segments is divided intotwo parts, in which one part is individually packed in packages andanother part is appended to packages containing respective encoded datasegments.

In one or more implementations, the present application includesarranging temporary storage of file data within a local cache by:operating over compound blocks of data; dividing memory space intoregions with compound blocks of equal size; employing a file structureto optimize file arrangement within the local cache; and performinggarbage collection to arrange free compound blocks.

In one or more implementations, the present application includes thatarranging temporary storage of file data within a local cache furtherincludes cache optimization employing information representing a filestructure.

In one or more implementations, the present application includes thatcache optimization is simplified by classifying files based onrespective a plurality of categories of access patterns, and employingrespective cache management strategy for similarly categorized files.

In one or more implementations, the present application includes asystem and method of data retrieval from remote storage nodes. Thisincludes accessing, by at least one processor configured to execute codestored in non-transitory processor readable media, file metadatareferences within a local cache or within remote storage nodes. Aplurality of packages are received, by the at least one processor, fromremote storage nodes by metadata references, each of the packagescontain file metadata. Moreover, a plurality of other packagescontaining encoded file segments are received, by the at least oneprocessor, from storage nodes by data references, wherein the encodedfile segments are obtained at least partly from file metadata. File dataare reconstructed from the packages as a function of metadatarepresenting parameters associated with an encoding scheme and filesplitting scheme.

In one or more implementations, the present application includes thatfile retrieval speed is enhanced by caching metadata from a plurality ofclient side files.

In one or more implementations, the present application includes asystem and method for erasure coding. This includes executing, by atleast one processor configured to execute code stored in non-transitoryprocessor readable media, data encoding with an error-correction code Cto produce N codeword chunks. The error-correction code C of length N=tnis based on 2 h component codes: h outer codes of lengths b_(i)n, 0≤i<h,and h inner codes of length t. The at least one processor distributes Ncodeword chunks over a set of storage nodes, wherein mapping of codewordchunks to storage nodes is optimized to balance network load. Further,the at least one processor reconstructs data chunks from codeword chunksrequested from storage nodes, and repairs data from erased codewordchunks that are reconstructed from other codeword chunks.

In one or more implementations, the present application includes thatdimensions of outer codes and length multipliers b_(i) are selected tomaximize a minimum distance of code C.

In one or more implementations, the present application includes thatprior to encoding, data are partitioned into K information chunks and,further comprising encoding, by the at least one processor, metadatainto at least one package, as multiplication of vectors having Kelements of information chunks by K×N generator matrix of code C,wherein the generator matrix comprises a K×K sparse matrix, such thatits inverse matrix is also sparse.

In one or more implementations, the present application includes thatK×N generator matrix of code C comprises a matrix obtained by column androw permutations from the K×K block-diagonal matrix.

In one or more implementations, the present application includes thatK×N generator matrix of code C comprises K×K block-diagonal matrix.

In one or more implementations, the present application includes that acodeword of code C comprises n groups of t elements, and further whereinany single erased codeword chunk within a group is repairable as alinear combination of other t−1 chunks of the same group.

In one or more implementations, the present application includesreconstructing erased codeword chunks by multi-stage decoding, wherein adecoding stage comprises decoding in one inner code and one outer code,and further where correction capability of employed inner codes increasewith stage index and stages are terminated upon recovering of allerasures within the codeword.

In one or more implementations, the present application includes that aninner code in a subsequent stage has a higher minimum distance than aninner code employed in previous stage.

In one or more implementations, the present application includes thatdimensions of outer codes kJ divided by respective length multipliers biconstitute non-decreasing sequence, k₀/b₀≤k₁/b₁≤ . . . ≤k_(h−1)/b_(h−1).

In one or more implementations, the present application includes thatthe outer codes are maximum distance separable codes.

In one or more implementations, the present application includes thatthe outer codes are Reed-Solomon codes.

In one or more implementations, the present application includes thatinner codes are nested codes having a same length and maximized minimumdistances.

In one or more implementations, the present application includes thatinner codes are a maximum distance separable codes.

In one or more implementations, the present application includes thatinner codes are binary linear block codes with maximum possible minimumdistances w_(i) and length multipliers b_(i) are such that w₀<w₁< . . .<w_(h−1).

In one or more implementations, the present application includes thatupdating of several information chunks, corresponding to the same sxssubmatrix of the block-diagonal matrix, results in no more than N−K+supdated codeword chunks, where N is the length and K is the dimension ofemployed error-correction code.

In one or more implementations, the present application includesretrieval of several information chunks, corresponding to the same s×ssubmatrix of the block-diagonal matrix requires s codeword chunks to bedownloaded from storage nodes.

BRIEF DESCRIPTION OF DRAWINGS

The invention is illustrated by the following drawings:

FIG. 1 is a schematic block diagram illustrating a distributed storagesystem interacting with client applications in accordance with anexample implementation of the present application;

FIG. 2 is a schematic block diagram representing logical components of aprocessing system arranged to transform original data into encrypteddata chunks, in accordance with an example implementation of the presentapplication;

FIG. 3 illustrates an example system including a plurality ofapplication servers, data vaults, and processes implemented in a virtualmachine instance, in accordance with an example implementation of thepresent application;

FIG. 4 is a simplified illustration of a package, in accordance with anexample implementation of the present application;

FIG. 5 illustrates data encoding and distribution, in accordance with anexample implementation;

FIG. 6 illustrates communications methodologies, in accordance with anexample implementation of the present application;

FIG. 7 shows processes and components in accordance with an exampleimplementation of the present application;

FIG. 8 illustrates an example architecture identifying pages anonymouslystored within a set of storage nodes, in accordance with an exampleimplementation;

FIG. 9 illustrates an example map showing storage nodes located aroundthe world;

FIG. 10 is a schematic data management illustration of data and metadatatransferring upon receiving write request from client application, inaccordance with an example implementation of the present application;

FIG. 11 is a schematic block diagram illustrating data processing andmetadata generation in the case of WRITE request, in accordance with anexample implementation of the present application;

FIG. 12 is a schematic block diagram illustrating building of datasegments from an individual file or from a group of files combined intological file, in accordance with an example implementation of thepresent application;

FIG. 13 is a schematic block diagram illustrating metadata processingand data reconstruction in the case of READ request, in accordance withan example implementation of the present application;

FIG. 14 is a schematic block diagram illustrating data and metadataremoval in the case of DELETE request, in accordance with an exampleimplementation of the present application;

FIG. 15 is a schematic block diagram illustrating removal ofunreferenced objects from the system in background regime, in accordancewith the an example implementation of present application;

FIG. 16 is a schematic block diagram illustrating encoding of a datasegment into a number of encoded chunks, in accordance with an exampleimplementation of the present application;

FIG. 17 is a schematic block diagram illustrating network load balancingfor transmission of a group of encoded chunks produced from relatedsegments, in accordance with an example implementation of the presentapplication;

FIG. 18 is a schematic illustration of server cluster cache and itsenvironment, in accordance with an example implementation of the presentapplication;

FIG. 19 illustrates components of cache located within each servercluster, in accordance with the an example implementation of presentapplication;

FIG. 20 shows logical structure of server cluster cache for objects, inaccordance with an example implementation of the present application;

FIG. 21 is a schematic block diagram illustrating memory allocation foran object, in accordance with an example implementation of the presentapplication;

FIG. 22 is a schematic block diagram illustrating removal of obsoleteobjects from a server cluster cache for objects in order to arrange freespace for new objects, in accordance with an example implementation ofthe present application;

FIG. 23 shows an example of file representation within the distributedstorage system, in accordance with an example implementation of thepresent application;

FIG. 24 shows an example of logical file metadata, in accordance with anexample implementation;

FIG. 25 is a schematic block diagram illustrating selection of a datarepresentation structure for file system management within servercluster cache for metadata, in accordance with an exampleimplementation;

FIG. 26 shows modules of a system, arranged to execute error-correctioncoding, in accordance with an example implementation;

FIG. 27 is a schematic block diagram illustrating the interrelationshipof modules of a system, arranged to execute error-correction coding, andenvironment of the system, in accordance with an example implementation;

FIG. 28 shows a flow diagram of steps executed within encoding module inthe case of system supporting only full block WRITE requests, inaccordance with an example implementation of the present application;

FIG. 29 is a schematic block diagram illustrating design of anerror-correcting code, where the error-correcting code specifiesconfiguration of other modules of the system, in accordance with anexample implementation of the present application;

FIG. 30 shows a flow diagram of steps executed within encoding module inthe case of system supporting both full block WRITE and part block WRITErequests, in accordance with an example implementation of the presentapplication;

FIG. 31 shows a flow diagram of steps executed to update encoded data ifonly a few elements of original data are modified, in accordance with anexample implementation of the present application;

FIG. 32 is a schematic block diagram illustrating initialization of loadbalancing module and steps performed to map encoded data to storagenodes, in accordance with an example implementation;

FIG. 33 shows flow diagram of steps executed within repairing module forreconstruction of erased elements of encoded data, in accordance with anexample implementation of the present application;

FIG. 34 shows flow diagram of attempts to repair encoded data usingdifferent strategies, in accordance with an example implementation ofthe present application;

FIG. 35 shows flow diagram of repairing steps corresponding tosingle-stage repair strategy, in accordance with an exampleimplementation of the present application; and

FIG. 36 shows flow diagram of repairing steps corresponding tomulti-stage repair strategy, in accordance with an exampleimplementation of the present application.

DETAILED DESCRIPTION OF EMBODIMENT

By way of overview and introduction, data security, system reliabilityand integrity are provided in a distributed storage system, such as in acloud storage system, including for client data. Security can beprovided by data encryption and secret sharing, and data segments can beencrypted as a function of individual encryption keys, which can befurther encrypted with key encryption keys (“KEKs”) that are distributedover storage nodes using secret sharing. KEKs can be generated using apassword-based key derivation function, wherein in which a password fora vault is employed together with random data. In one or moreimplementations, KEKs are stored on the client side. In case of systemfailure, such as a client side crash, a copy of a KEK may be retrievedfrom storage nodes using a single password. Protection against dataloss, caused by storage node failures (e.g., commodity hardwarefailures), is provided by erasure coding. Moreover, erasure coding helpsto tolerate storage node outages, while high storage efficiency isprovided by selected construction of error-correction code, such asshown and described in greater detail herein. Code parameters (e.g.,length, dimension, minimum distance) can be determined as a function ofa vault configuration of a respective client. Accordingly, code lengthshould not exceed the number of storage nodes specified in the vaultconfiguration, and a number of tolerated storage nodes failures is equalto the minimum distance decreased by one. Storage efficiency can beenhanced by flexible deduplication. Furthermore, deduplication can beperformed for not just files, but also for small parts or pieces offiles. The present application accounts for an appropriate tradeoffbetween deduplication complexity and storage efficiency, which can beselectable by a client. Further, optional compression can be applied todata, depending on respective client preferences. Latency for dataretrieval and repair operations can be further minimized by network loadbalancing technique such as shown and described herein.

Accordingly, present disclosure relates to distributed secure datastorage and transmission for use in various contexts including, forexample, streaming and other applications. The dispersed storage ofdata, including in particular streaming media data, on cloud servers isone particularly useful application, while similarly applicable toconfigurations in which data may be stored on multiple storage deviceswhich may be connected by any possible communications technology such aslocal area and/or wide area networks. In certain embodiments thisincludes storage of media content, including without limitation video oraudio content, that can be made available for streaming through theInternet. The disclosed improvements in speed and security, and greaterutilization of available storage resources can enable higher streamingrates. The vast amount of storage space required for storage of video,audio and other metadata can further benefit from increased availabilityand utilization of existing resources and infrastructure, in accordancewith respective implementations embodiments disclosed herein.

In one or more implementations, data that are stored within adistributed storage system can be classified into several categories,and different coding techniques can be applied to different datacategories. Thus, for example, erasure coding techniques maximizingstorage efficiency can be applied to a plurality of files containingoriginal data, and highly utilized metadata techniques can be selectedand applied to minimize access latency. Further, high speed dataretrieval is possible as a function of reconstructing data fromdifferent subsets of storage nodes. In case a number of availablestorage nodes is not less than a pre-defined threshold, data recovery ispossible.

In one or more implementations, a distributed storage system of thepresent application is object-level one, in which files withcorresponding metadata are abstracted as objects. Further, small filescan be aggregated into one single object to reduce the number of objectsto be transmitted to storage nodes, and to reduce amount of metadata.Objects can be partitioned into segments, and each segment can befurther encoded. Thus, a number of encoded chunks are produced from eachsegment. Encoded chunks together with corresponding metadata areencapsulated in packages, which are transferred to storage nodes. Clientdata is securely stored within the encoded chunks by utilizingencryption and erasure coding with pre-defined degree of data mixing. Inaccordance with the present application, no amount of client data may bereconstructed from any set of encoded chunks, provided cardinality ofthe set is lower than the mixing degree. Further, sizes of segments andencoded chunks can be selected as a function of respective clientstatistics, including statistics on read and write requests. Thus,several data segment sizes are supported in accordance with theteachings herein. The size of a respective encoded chunk can bedetermined by the size of a related segment and the number of storagenodes and/or the length of selected error-correction code.

According to one or more implementations of the present application, adistributed storage system is provided that includes processing systemdevices configured to distribute and/or access client data quickly andefficiently over a set of storage nodes. Processing system devices caninclude one or several server clusters, in which each server cluster isconfigured with or as a file system server and a number of processingservers. A specially designed object-based file system can be includedand deployed within each server cluster. File system servers of theserver clusters can operate to maintain identical instances of theobject-based file system. More particularly, a frequently used part ofan object-based file system may be maintained within the processingsystem, while an entire object-based file system can be packed in aplurality of encoded chunks, encapsulated into packages and, thereafter,distributed over a set of storage nodes. Object search speed is,accordingly, enhanced as a result of selection of an appropriate treedata structure or a directed graph. An example object-based file systemof the present application operates over large data blocks, referred ascompound blocks. Compound blocks significantly reduce an amount ofmetadata, the number of operations performed by the object-based filesystem and the number of objects transmitted to storage nodes. In one ormore implementations, a merging of NAS technology and object storage isprovided, wherein files are also configured as objects, each having aunique ID. This provides the ability for files to be accessed from anyapplication, from any geographic location and from any public or privatestorage provider, with simple HTTPS protocols, regardless of the sameobject being filed in a sub-folder on the NAS file system. This furtherprovides enterprise applications with a multi-vendor storage solutionthat has all benefits of object storage.

Implementations of the present application allow for mixing of storagenodes from multiple vendors, and provide functionality for users toselect any respective ones of storage providers, including on-site andoff-site, and to switch between storage providers at will. Moreover, byproviding key storage at the client level, block and file system storageis configured to meet the needs of an increasingly distributed andcloud-enabled computing ecosystem. With block-based storage, blocks ondisks are accessed via low-level storage protocols, such as SCSIcommands, with little overhead and/or no additional abstraction layers.This provides an extremely fast way to access data on disks, and varioushigh-level tasks, such as multi-user access, sharing, locking andsecurity, can be deferred to operating systems.

In one or more implementations of the present application, erasure codechas been developed for implementing secure cloud NAS storage with arelatively simple file system. The codec configures an erasurecorrecting code from component codes of smaller lengths. A library ofcomponent codes that includes optimal maximum distance separable (MDS)codes (such as Reed-Solomon) and codes with low encoding/decodingcomplexity (such as optimal binary linear codes) can be provided, andthe structure of the erasure code can be optimized to the user'spreferences. This structure provides erasure coding with flexibleparameters, such as to enable users to manage storage efficiency, dataprotection against failures, network traffic and CPU utilization. Toensure low latency, the erasure codec of the present applicationdistributes network traffic, in conjunction with load balancing.

Moreover, storage efficiency can be enhanced by using MDS componentcodes, and network traffic and computational complexity are reduced byusing linear codes over small, finite fields. For example, the number ofcomponent codes within the configured erasure correcting code of thepresent application can depend on a number of available storage nodes,which can further be determined by a data vault's respective structure.

In accordance with the present application, erasure codec includes animproved performance algorithm for data processing by maximizinginput/output operations per second (“IOPS”) ratio by using concurrencyand parallel processing. This can reduce latency and avoid operationallimitations within datacenters. Moreover, configurations of the presentapplication can obtain significantly high levels of security, such as toprotect customer data within public or private cloud premises fromunauthorized access and theft, by mixing and hiding data as a functionof the erasure codec. In one or more implementations, a degree of datamixture can be selected according to user preference. The mixture degreecan be the smallest number of storage nodes that need to be accessed inorder to reconstruct a chosen amount of original user data. Highermixture degrees can correspond to higher levels of data protection, suchas to preclude unauthorized access, and to provide higher data retrievalcomplexity.

Referring now to the drawings, FIG. 1 is a schematic block diagramillustrating a distributed storage system interacting with clientapplications, in accordance with an example implementation of thepresent application. Original data 106, e.g., files, produced by clientapplications 109, are distributed over a set of storage nodes 103, andoriginal data 106 is available to client applications 109 upon request.Any system producing and receiving data on the client side can beconsidered as an instance of a client application 109. Further, dataprocessing and transmission control are arranged by processing system101, located on the client side. According to the present application,processing system 101 can include one or several server clusters 107, inwhich original data 106 are transformed into encoded chunks 108, andvice-versa. As noted herein, generally, a server cluster 107 can includea file system server and one or more processing servers, although aserver cluster may include just an individual server.

Client applications 109, processing system 101 and storage nodes 103communicate via a data communication network, such as the Internet.Storage nodes 103 can operate independently from each other, and can bephysically located in different areas. Processing system 101 ensuresdata integrity, security, protection against failures, compression anddeduplication. In one or more implementation, configuration ofprocessing system 101 is specified by configuration metadata 104maintained within highly protected storage 102. System configuration maybe adjusted via administrator application 110.

FIG. 2 is a schematic block diagram representing logical components ofan example processing system, and arranged to transform original datainto packages with encapsulated encoded chunks, and vice-versa, as wellas to organize fast, reliable and secure data transmission. FIG. 2illustrates an example logical architecture, as opposed to the examplephysical architecture illustrated by FIG. 1. In FIG. 2 processing system201 includes a number of modules, wherein each module is responsible fora particular functionality.

Features and functionality shown and described herein is described inthe general context of computer system executable instructions, such asprogram modules, being executed by one or more computer systems.Generally, program modules include routines, programs, objects,components, logic, data structures, and so on that perform particulartasks or implement particular abstract data types. In a distributedcloud computing environment, program modules can be located in bothlocal and remote computer system storage media including memory storagedevices. Accordingly, modules can be configured to communicate with andtransfer data to each other.

In one or more implementations of the present application, one or moreclient applications 202 can operate on application level 210. From theview of a leveled architecture, modules can be divided into twocategories. A first category can include modules operating on particularlevels. For example, administrator module 215 operates on applicationlevel 210, and can be responsible for providing relevant information toa system administrator regarding tasks being performed, configurationinformation, monitoring information and statistics on the system moregenerally, as well as for receiving administrator's orders. Originaldata can be received by gateway module 203 operating within access level211, where gateway module 203 supports different protocols, e.g.,network file system (NFS) protocol, server message block (SMB) protocol,internet small computer system interface (iSCSI) protocol,representational state transfer (REST) or RESTful Web services. Gatewaymodule 203 can provide opportunity for almost any arbitrary database orapplication on the client side to access the processing system 201.Moreover, gateway module 203 can enable communication between processingsystem 201 and storage nodes via the network (e.g., using hypertexttransfer protocol secure (HTTPS)).

Thus, operation in network level 213 gateway module 203 provide forconnectivity between data processing level 212 and object storage level214. Transformation of original data into encoded chunks can beperformed within data processing level 212. In one or moreimplementations, two modules operate in data processing level 212: filesystem module 204 and coding module 205. Coding module 205 can beconfigured to perform compression, encryption and erasure coding, whilefile system module 204 can be configured to keep track of correspondencebetween original data objects and packages with encoded chunks locatedon storage nodes. Load balancing module 206, while operating in networklevel 213, can be configured to minimize, for example, regulatingtraffic between processing system 201 and each storage node. Loadbalancing module 206 can perform bandwidth analysis and use resultstherefrom to optimize mapping between a set of encoded chunks and a setof storage nodes, i.e., to optimize distribution of packages overstorage nodes.

A second category of modules can include modules that are configured toaffect or arrange functioning of other modules. For example,configuration module 207 is operable to customize other modulesaccording to configuration metadata. Control module 208 can includeinstructions that, when executed by one or more devices withinprocessing system 101, to schedule tasks for other modules and toregulates resource consumption, e.g., memory and CPU. Monitoring module209 can be configured to include instructions that, when executed by oneor more devices within processing system 101, to activity track onactivities being performed within the processing system 101 and itsenvironment, as well as to generate event alerts, as appropriate.

Modules can be distributed over a server cluster, i.e., file systemserver and processing servers. Thus, file system module 204,configuration module 207 and gateway module 203 are deployed over filesystem server. Coding module 205 and load balancing module 206 aredeployed over processing servers. Control module 208 and monitoringmodule 209 are deployed over both file system server and processingservers.

As noted herein, the present application configures one or moreprocessing devices to partition objects into segments, and each segmentcan be further encoded into a number of chunks, which can be transferredto storage nodes. This structure significantly simplifies storageimplementation processes, without compromising data security, integrity,protection and storage performance. For example, and illustrated in theexample implementation shown in FIG. 3, information about data isencrypted at the client and stored securely within packages withencapsulated encoded chunks that are dispersed across storage nodes. Asillustrated in the example system 300 in FIG. 3, a plurality ofapplication servers, data vaults, a process is implemented in a virtualmachine instance that includes operations for, for example, encryption,compression, deduplication, and protection and, moreover, slicing theinformation into a respective chunks and objects. The erasure codecgenerates various types of encoded chunks, which are spread across allthe storage nodes and deployed for a vault installation.

Moreover and with reference to the example package with encoded chunk400 shown in FIG. 4, metadata can be encoded in a way that is onlyvisible and retrievable by the authorized data owner. This isimplemented by abstracting erasure-coded metadata and NAS metadata,which is thereafter dispersed between different storage nodes. A packagecan be configured to contain encoded chunk together with relatedmetadata: storage nodes configuration; a vault configuration; a link toactive vault snapshot; and a current state of data blocks used forsnapshot.

The result is a simple NAS solution with all advantages of erasure-codedobject storage, such as security, unlimited scalability, speed and dataresiliency and without a requirement for use of RAID systems to providedata resiliency, and write or replicate multiple copies to differentgeographical locations to ensure availability during component failures.The systems and method shown and described herein provide for dataprotection, while including a relatively modest overhead (e.g., such as40%-60% overhead), as opposed to a significantly larger overhead (e.g.,300-600% overhead) in traditional NAS systems.

In one or more implementations, packages that are generated fromoriginal data are connected by shared base information, as well as byconnectivity to one or more neighboring packages through metadata. Thepackages can be uploaded to geographically distributed storage nodes ofthe user's choosing, and contain links to a vault snapshots, as well asa current state of data blocks used for the snapshots. This providessignificantly enhanced security and gives the vault a high tolerance fornode failure. Moreover, the present application supports the ability toreconstruct all data, even in the event of data loss on the client side.Simply by creating a new vault with account details, all data willbecome instantly accessible. This can be further made possible as afunction of the intelligent indexing and caching data prior to datauploading to remote storage nodes, as well as data pre-fetching prior toreceiving read requests. Unlike traditional block storage behind NAS,which works in 4 KB blocks of data and requiring a large infrastructureto manage, the present application operates with increased block size,and combines the blocks into compound blocks that are independentlymanaged and subject to self-healing methodologies. For example, adefault size of a compound block can be 4 MB. These larger blocks ensurenear Tier-1 performance on top of S3-type storage nodes.

In one or more implementations, data blocks can be categorized such as“hot,” “warm” and “cold.” Rating indexes can be managed for NAS blocks,and these rating indexes can be further employed to identify a categoryof a corresponding compound block. In this way, frequently used warm andhot categories of data can be handled locally (in memory and stored inlocally attached SSD), while also being dispersed in the cloud.Furthermore, the cached part of file system is regularly snapshotted,sliced, turned into packages with encoded chunks, and then distributedover storage nodes. If a cache includes several independent storagedevices, e.g., several SSD, then replication or erasure coding can beemployed within cache to enhance data protection. An example process 500is illustrated in FIG. 5.

With reference to the example communication methodology and distributedapplication shown in FIG. 6, a virtual appliance provides a distributed,scalable, fault-tolerant and highly available storage system, whichallows organizations to combine geographically distributed storageresources of different providers into a single namespace that istransparent, for example, on UNIX and WINDOWS operating systems, Inoperation an instance can be provisioned as a virtual appliance ordocker container, which can run under a virtualization framework, suchas VMware, Xen or OpenStack. Alternatively, it can be easily packaged ona hardware appliance.

Example processes and components 700 are illustrated in FIG. 7, andinclude an object storage layer, splitter, iSCSI, network file system(e.g., NFS), common internet file system (“CIFS”), mounted file system(for example, ext4 or btrfs), block storage, cache, and public andprivate cloud connectors. In one or more implementations, an objectstorage layer ensures consistent integration with public and privatestorage nodes. The object storage of the present application issignificantly more scalable than traditional file system storage, atleast in part because it is significantly simpler. For example, insteadof organizing files in a directory hierarchy, object storage systemsstore files in a flat organization of containers, and unique identifiersare employed to retrieve them.

Data splitting can be configured to perform three major operations on astored data object: data slicing and mixing; high level encryption (forexample, using AES-128, AES-196 or AES-256); and data encoding againstfailures with an efficient and flexible algorithm. Data encoding can beconfigured to work in such a way that the produced encoded chunks do notcontain any sequence of bytes from the original data object, even withthe encryption option, for example, in the administrator application110, being set to disabled.

With reference now to the example architecture 800 illustrated in FIG.8, packages with encoded chunks can be anonymously stored within a setof storage nodes. In one or more implementations, transformed datablocks are transmitted to different storage nodes in parallel, ensuringefficient utilization of available network bandwidth, which results inhigh data transfer speed. This strategy makes data interceptionvirtually impossible. Moreover, vault snapshots, data blocks andpackages with encoded chunks, described in greater herein, form a graphof related data objects. An example map 900 showing storage nodeslocated around the world is illustrated in FIG. 9.

In one or more implementations, a fast, key-value pair-based, graphdatabase is used to access various information about the state of thesystem. These include, for example finding the latest valid vaultsnapshot, the closest snapshot for rollback, and data blocks that mayneed repair.

In one or more implementations, a full system configuration can bereplicated to a subset of storage nodes on a regular basis. This ensuresthat data can survive an underlying virtual machine (VM) server outage,and that the system state can also be restored if the VM data isdestroyed. Vault snapshots can include the following metadata: a list ofthe data blocks used; checksums for verifying data blocks integrity; abase snapshot image; blocks delta overlaid over base vault snapshot; anda link to previous vault snapshot used.

With regard to NFS File Sharing Services, in one or more implementationsof the present application, the full range of NFS security can besupported. With regard to vault options, a range of vault types can beconfigured to support different application configurations. For example,vaults can be created and configured for file storage, archiving and/ordeep archiving. Vaults can further be optimized for running block-baseddatabases, imaging (e.g., video) and image storage applications.

In one or more implementations, a primary storage vault is provided fora high performance file system. With vault content cached locally, thisoption is ideal for database applications. Files can be stored in avirtual folder, and managed in the background. The primary storage vaultsupports automatic snapshot management, wherein snapshots are createdmuch faster than backups, and each snapshot is consistent with thesource content at the moment of its creation. The frequency of snapshotscan be defined, and snapshots can be split and dispersed to differentdatacenters in the cloud, such as shown and described herein. Thus, dataare protected and backed up frequently, without the performance ofapplications being negatively affected.

With reference to vault management, a high performance cloud storagefile system is provided with virtually unlimited storage capacity. Thisoption is ideal for web servers requiring large storage capacity forimages and videos, and fast performance. Data can be stored acrossmultiple cloud centers, and be managed by a single file system that canbe accessed almost instantaneously from other members of the clusterlocated in other geographical regions. For example, data can be storedin multiple vault clusters, using a MICROSOFT AZURE data center inIreland, an AWS data center in Virginia and an on-premises data centerin Singapore.

In one or more implementations, an archive vault option provides longterm storage of data that is compressed and deduplicated. The data canbe compressed automatically, which is useful in cases when low storagecosts are desired and moderate retrieval speeds are tolerable.

In one or more implementations, another archive vault offers lowerstorage cost compared to other archive vault options. This option may beideal for data that are rarely retrieved, and data retrieval times areless important. Such an option may be implemented using AMAZON GLACIERcloud storage, and provides long term storage of data that is compressedand deduplicated. Alternatively, WINDOWS file sharing via CIFS protocolprovides file sharing with WINDOWS servers and WINDOWS clients,including WINDOWS 7, WINDOWS 8, WINDOWS XP and other WINDOWS-compatibledevices. Virtually an unlimited number of file shares are supported.

Performance of the system can scale linearly with a number of storagenodes in the system. Accordingly, adding a new storage node willincrease the available capacity and improve the overall performance ofthe system. The system will automatically move some data to the newlyadded storage node, because it balances space usage across all connectednodes. Removing a storage node is as straightforward as adding a node.The use of multi-vendor storage nodes allows the system to parallelizeoperations across vendors, which further contributes to its throughput.

Moreover, the teachings herein provide benefits of secret sharingschemes to storage by combining information dispersal with high levelencryption. This preserves data confidentiality and integrity in theevent of any of the packages with encoded chunks being compromised. Themethods of data coding ensure that information can only be deciphered ifall the information is known. This eliminates the need for keymanagement while ensuring high levels of key security and reliability.Data can be packaged with AES-256/SHA-256 encryption which is validatedfor use in the most security conscious environments.

As noted herein, the present invention is directed to object-baseddistributed storage systems. According to one or more implementations ofthe present application, files with corresponding metadata can beabstracted as objects. Object metadata can include original datametadata and system metadata, in which original data metadata isprovided by client applications together with related files, and systemmetadata can be generated by object-based distributed storage systemapplication(s). Thus, original data metadata does not have to depend onobject-based distributed storage system in general (i.e., processingsystem or cloud storage). Further, original data metadata can includefile attributes such as file type, time of last change, file ownershipand access mode, e.g., read, write, execute permissions, as well asother metadata provided by client application together with the filecontaining original data. Original data metadata can be encoded andencapsulated into packages, together with original data.

In one or more implementations, system metadata of an object is usableto manage an object within the distributed storage system, so it isparticularly relevant from within the system. System metadata caninclude identifiers, cloud location information, erasure coding scheme,encryption keys, internal flags and timestamps. Additional systemmetadata can be specified depending on the requirements to thedistributed storage system. Here, identifiers, e.g., numeric IDs andHASH values, are usable to identify objects and their versions. Cloudlocation information can be represented by an ordered list of datasegments, in which each segment is given by a list of packages withencoded chunks (e.g., indices and locations). An index of a package candepend on a load balancing scheme. Further, a location of a package canbe provided by a reference, thereby providing an opportunity to downloada package with encoded chunks from cloud storage. Information regardinga respective erasure coding scheme is usable to reconstruct datasegments from encoded chunks. Moreover, secure storage of encryptionkeys can be provided by using key encryption keys (KEKs), in which KEKsdepend on password or, alternatively, by distribution over storage nodesusing secret sharing. Internal flags show various options that areenabled for an object, e.g., encryption, compression, access type, andcaching policy. Further, timestamps identify a time of object creation,modification and deletion. Timestamps are useful to track a relevantversion of an object. Of course, this list of metadata is exemplary, andcan be supplemented or detailed.

In accordance with one or more implementations, a distributed storagesystem for a particular client can be specified by configurationmetadata that include: vault configuration; erasure encoding scheme;encryption scheme; compression scheme; deduplication scheme; accesscontrol information; flags showing enabled options; and reference forfile system root. In operation, a client has access to his/her storagespace configured in a vault or a number of independent vaults.Respective coding techniques, i.e., encryption, erasure coding,compression, and namespace can be specified for respective vaults. Eachvault can be logically divided into volumes, and each volume may becreated to store a particular type of data or for a particularuser/group of users. Furthermore, access rights and data segments sizescan be specified for a volume.

FIG. 10 is a schematic illustrating of example data and metadatatransferring upon receiving WRITE request from client application. Aclient request is received by one of server clusters 1006, moreparticularly, by the gateway module. As noted herein, each servercluster 1006 can include a file system server and a number of processingservers. Typically, a gateway module is located within file systemserver. At step 1, a WRITE request with a piece of file 1001 istransferred via communication network to gateway module. A networkprotocol employed for data transferring can depend on a clientapplication, e.g., protocols SMB, NFS, CIFS, iSCSI and RESTful API. Inone or more implementations, only one client application is permitted towrite to a particular file at one time, which may be implemented usinglock/unlock in file system servers, managed by the leading file systemserver 1007. Upon receiving WRITE request 1001, server cluster 1006performs coding of file segments into encoded chunks 1002 and generatesobject metadata. Then at step 2 server cluster 1006 initiates a PUTrequest for each package with encoded chunk, produced from the piece offile. At step 3, a wait occurs for acknowledgements 1003 upon successfulplacement of packages. Object metadata, utilized by the object-baseddistributed storage system, can be distributed over storage nodes 1008and partially cached within file system servers. In order to maintainidentical partial copies of the object-based file system within eachserver cluster, the leading server cluster with the leading file systemserver 1007 is selected. Leading server cluster is temporary assignedusing some consensus algorithm, e.g., Raft. At step 4, metadata 1004 istransmitted to the leading file system server 1007, which retransmits itto other file system servers at step 5. Thus, metadata 1004 isdistributed over the set of server clusters. At step 6 the leading filesystem server 1007 is waiting for acknowledgements, in order toguarantee data integrity. If some server cluster is unavailable at agiven moment, then the leading server cluster monitors status of thisserver cluster and arranges metadata 1004 transferring, as soon aspossible. In case the leading server cluster is unavailable, anotherserver cluster can be assigned as a leading one, for example, accordingto an employed consensus algorithm. At step 7 server cluster, connectedwith the client application 1005, receives acknowledgement from theleading server cluster. Then at step 8, acknowledgement on successfullyperformed WRITE operation is sent to the client application 1005.

FIG. 11 is a schematic block diagram illustrating example dataprocessing and metadata generation in the case of a WRITE request.Gateway module of the processing system receives a WRITE request with apiece of file 1101, in which the file is specified by a uniqueidentifier (ID), while an original data piece within the file isspecified by offset indicating beginning of the piece and length of thepiece. File attributes can be treated as original data metadata andencapsulated into packages together with data segment. Thus, relevantfor the distributed storage system, file attributes 1109 are copied atstep 1102. Segmentation of the file piece is performed at step 1103(illustrated in additional detail in FIG. 12). Obtained parts of a fileare employed to update an existing data segment or stored as new datasegments. At step 1104 (illustrated in additional detail in FIG. 16),each new/updated data segment is encoded into a set of data chunks, inwhich encoding procedure includes deduplication, compression, encryptionand erasure coding. In one or more implementations, compression anddeduplication can be optional.

Further, in one or more implementations, encryption can be optional forlow important data. Prior to actual encoding, HASH value 1110 iscomputed for each data segment, wherein a cryptographic hash function isemployed, e.g., BLAKE2, BLAKE, SHA-3, SHA-2, SHA-1, MD5. Encryption keys1111 may be based on HASH values 1110 or generated independently fromcontent using random data. HASH values 1110 and encryption keys 1111 areconsidered to be a part of system metadata, since knowledge thereof isrequired to reconstruct original data. Packages are assigned to storagenodes at step 1105, in which network load is jointly balanced forpackages with encoded chunks, produced from several related datasegments (illustrated in additional detail in FIG. 17). At step 1106packages are transferred from the processing center to storage nodes,where storage nodes send back to the processing center acknowledgmentsupon saving of packages. A data reference (DR) can be generated for eachtransferred package, in which the DR is an address of package within astorage node. Given DR for a package and permission, the package may beaccessed within a storage node. In one or more implementations, a listof DRs 1107 is appended to system metadata of file piece, therebyproviding complete object metadata that is obtainable at step 1108. Atstep 1112 object metadata is encoded to guarantee security andreliability. For example, object metadata can be encoded in the same wayas a data segment, as well as just encrypted and protected againstfailures using erasure coding or replication. At step 1113, objectmetadata is transferred to storage nodes, and acknowledgements arereceived by the processing system 101 thereafter. Access to metadata,distributed over storage nodes, can be provided using generated metadatareferences (MDRs). As used herein, an MDR has the same general meaningfor metadata as DR for data. At step 1114 and relevant for a systemobject, metadata is spread over server clusters and tree/graph structureof the object-based file system is updated. Upon completion ofoperations, an acknowledgement 1115 is sent to the client application.

FIG. 12 is a schematic block diagram illustrating example building ofdata segments from an individual file or from a group of files combinedinto a logical file. Segmentation of a file 1201 can be performeddepending on the file size. More particularly, if a file size is above apre-defined threshold 1202, then it can be individually packed into anumber of encoded chunks. Such files are referred to herein, generally,as large file, while files with a size lower than the threshold arereferred to as small files. For example, a value of such threshold maybe less than the segment size. If a file 1201 is the large file then, atstep 1203, the file 1201 is partitioned in the number of data segmentsof specified size. For a small file, an attempt to pack several filesinto one data segment is made. Thus, at step 1204 the system checkswhether the present file 1201 may be combined with already accumulatedfiles or with the next small files. In the latter case, the file 1201 isconverted into a data segment at step 1205. In the former case, the file1201 is embedded into a current logical file, where the logical file isa container for small files. The size of a logical file is defined inone or more implementations, to be equal to the size of a respectivedata segment. In some scenarios, a logical file can be treated as alarge file, while in other scenarios it is treated as a set of smallfiles. Logical files are built at step 1206 using two principles: packrelated (dependent) small files together and to decrease wasted storagespace. For example, it is preferable to pack together files that arelocated in the same folder. Here wasted storage space represents by thesum of differences between data segment sizes and logical file sizes.Accordingly, it can be desirable to produce logical files of a size thatis as near to a data segment size as possible. At step 1207, adetermination is made whether a current logical file is complete, i.e.,no more small files are to be embedded. In the case of completeness, thesystem can convert the logical file into data segment at step 1205 andcreate a new current logical file. Obtained data segments 1209 can befurther transferred. Observe that if several small files are embeddedinto the same logical file, then IDs of these files are associated withthe same logical file root MDR, where file root MDR is MDR, which isunique for the file and which provides access to all file data andmetadata.

FIG. 13 is a schematic block diagram illustrating example metadataprocessing and data reconstruction, in the case of READ request. Theprocessing system receives READ request for a piece of file 1301, inwhich a file is specified by file ID, a piece within the file isspecified by offset, indicating beginning and length of the piece, as inthe case of WRITE request illustrated in FIG. 11. At step 1302, the fileroot MDR is identified by given the file ID in a tree/graph structure ofthe object-based file system, in which a file is represented by a nodecontaining a file root MDR. The tree/graph structure of the object-basedfile system can be partially cached within the processing system. If arequired node is not found in the processing system cache, then a partof the tree/graph structure containing this node can be retrieved fromstorage nodes and stored in the cache. An obtained file root MDR 1308can be employed to retrieve object metadata using other MDRs related tothe file, at step 1303. In one or more implementations, object metadataincludes information regarding an object location, such as a list ofdata segments produced from the object (file) and an ordered list of DRs1310 for each data segment. At step 1305 packages with encoded chunks,related to the required file piece 1301 are independently retrieved fromthe set of storage nodes. These packages may be retrieved in any order.At step 1306 original data segments are recovered by coding module fromencoded chunks. Data segments, combined into file piece in location 1311at step 1307, where memory is provided within the processing systemcache and allocated at step 1304 using a list of segment sizes 1309. Asresult, acknowledgement with specified file location and metadata 1312is transferred to the client application, from which the read requestwas initiated. Thus, access to the requested file piece is provided bythe location within the processing system cache.

FIG. 14 is a schematic block diagram illustrating example data andmetadata removal in the case of a DELETE request. This diagramcorresponds to an example case when an option for deduplication isenabled. In such case, several links to the same object are possiblewithin the object based file system, e.g., as induced by existence oflogical files. Upon a DELETE request with specified file ID 1401, a filesystem server identifies the file root MDR, at step 1402. Observe thatonly one file root MDR preferably corresponds to a file ID. Twoimplementations of deduplication are considered herein. In case ofdirect deduplication, all unreferenced objects are deleted instantly,while according to the second approach periodical garbage collection isemployed as a background process in order to delete all unreferencedobjects. In the latter case, only obtained file root MDR 1403 is removedupon a DELETE request, at step 1410, since each package with encodedchunk is referenced only once. If direct deduplication 1404 is enabled,then MDRs with a list of DRs 1406, related to the file root MDR 1403,are recovered as a part of object metadata at the step 1405. The list ofDRs 1406 is further employed at step 1407 in order to find MDRs of allobjects, which use the same packages with encoded chunks as the file tobe deleted. At step 1408, packages, utilized only by the file with ID1401 are deleted. Further, metadata corresponding to deleted files isremoved at step 1409. Finally, file root MDR for the file with ID 1401is also deleted from the object-based file system, at step 1410. Thus,all information about the file with ID 1401 is removed from thedistributed storage system, with the exception of journal logs. A listof deleted objects can be maintained within journal logs for possiblesubsequent garbage collection and for statistics needs.

In the event that an option for deduplication is disabled, then MDR, DRsand packages with encoded chunks related to the file are simply removedupon DELETE request. This corresponds to file deletion operation givenby steps: 1402, 1405, 1408, 1409 and 1410.

FIG. 15 is a schematic block diagram illustrating example removal ofunreferenced objects from the system in background regime. This processmay be considered as garbage collection, in which garbage is representedby unreferenced objects stored in the processing system 101 and the setof storage nodes. Garbage collection can be implemented as a backgroundprocess, i.e., periodical search for unreferenced objects with theirsubsequent removal is performed without termination of requestprocessing. Thus, in the case of deduplication with garbage collection,a DELETE request can be executed with much smaller latency than in thecase of direct deduplication. An example garbage collection processoccurs as follows. At step 1501 a search for unreferenced DRs isperformed, where an unreferenced DR is a DR, which does not listed inmetadata of any object. At step 1503 packages with DRs, specified by theobtained list of unreferenced DRs 1502, are deleted from storage nodes.Finally, unreferenced DRs 1502 are deleted at step 1504.

Garbage collection activities can be scheduled depending on systemworkload. Thus, network resources, memory resources and computationalresources are utilized for garbage collection in periods of lowworkload.

FIG. 16 is a schematic block diagram illustrating example encoding of adata segment into a number of chunks. Steps shown at FIG. 16 areexecuted by a coding module, which is responsible for data encoding anddecoding. Data segment 1601 of pre-defined size is received as inputargument. Data segment 1601 is treated by the coding module asunstructured data, so only size of the data segment 1601 is relevant andno assumptions about content of the data segment 1601 are made.Integrity check is made upon data segment retrieval. Optionaldeduplication may be performed at step 1603. Different levels ofdeduplication are possible, e.g., segment-level deduplication, which isperformed by comparison of HASH values for data segments of the samesize, stored within the distributed storage system. Optional compressionmay be performed at step 1604. If a compression option is enabled, thentotal or selective compression is performed. A compressiontransformation is applied to each data segment in the case of totalcompression. In the case of selective compression the compressiontransformation is applied at first to a piece of data segment. If areasonable degree of compression is achieved for the piece, then thecompression transformation is applied to the whole data segment. A flagshowing whether compression was actually applied is stored withinpackages with encoded chunks. Compression can be performed prior toencryption, to obtain a fair degree of compression.

In one or more implementations, an encryption step 1605 is mandatory fordata segments with high secrecy degree, while optional in others. Byenabling/disabling encryption for different secrecy degrees, tradeoffbetween security and computational complexity may be arranged. Ifencryption 1605 is enabled, then a segment can be encrypted as a whole,or it can be divided into several parts and each part is separatelyencrypted. The former strategy is referred to herein, generally, assegment level encryption, while the latter strategy is referred as chunklevel encryption. Segment level encryption strategy can allow only fullsegment READ/WRITE requests, so in case partial READ/WRITE requests arerequired by the processing system 101, then chunk level strategy isselected. A strategy is identified at step 1606. In case the segmentlevel encryption strategy is employed, the following steps can beperformed: encryption of the full (optionally compressed) data segment1607 and partition of encrypted data segment into K chunks of equal size1608, where value of K depends on selected erasure coding scheme. In thecase of chunk level encryption strategy, at first (optionallycompressed) data segment is partitioned into K chunks 1608, then chunksare separately encrypted at step 1609, where each chunk is encryptedwith the same key, i.e., a key per segment, or with an individual key,i.e., K keys per segment. Thus, each segment has one or severalindividual encryption keys, so possibility of a malicious adversaryaccessing all data using one stolen key is eliminated.

Erasure coding can be applied to protect data against storage nodefailures and provide fast data retrieval even if some storage nodes areunavailable, e.g., due to outage. Observe that erasure coding provideshigher storage efficiency compared to replication. For example, in thecase of triple replication two faults can be tolerated and storageefficiency is 33%. The same fault tolerance can be easily achieved withReed-Solomon code of length 10 and dimension 8, providing storageefficiency 80%.

Moreover, erasure coding of obtained K chunks into N codeword chunks isapplied at step 1610, in which an error-correction code of dimension Kand length N≥K is used. A relative size of codeword chunks can be thesame as the size of information chunks. During erasure coding each chunkis considered as a vector of symbols and i′th symbols of K informationchunks are erasure coded into i′th symbols of N codeword chunks, inwhich symbol size is defined by error-correction code parameters. Thus,computations for symbols with different indices are performed inparallel, e.g., using vectorization.

According to one or more implementations, advanced encryption standard(AES) is utilized for encryption. Individual encryption keys forsegments that are encrypted with KEK, generated using password-based keyderivation function (PBKDF2), in which the password for thecorresponding vault is employed and salt (random data), e.g., 32 bytes.The length of encryption key may be different, e.g., 128, 192 or 256bits. Moreover, encryption is performed iteratively, where the number ofrounds is set sufficiently high in order to provide desirable level ofsecurity. The number of rounds is also encoded within a package.

Selection of encryption strategy can depend on a client's preferences.In the case of segment level encryption strategy, the smallest amount ofredundancy is introduced. However, this strategy allows only fullsegment READ and WRITE requests, since data may by encrypted anddecrypted only by segments. If partial READ and WRITE requests areneeded, then chunk level encryption strategy can be employed. Observethat the last strategy allows to read and write data by chunks. Chunklevel strategy with K individual keys provides higher security level,however, it also introduces the highest redundancy.

Upon execution of all steps, represented at FIG. 16, one obtains anordered list of encoded chunks 1611, where a local index of a packagewith encoded chunk corresponds to a chunk position within codeword ofemployed error-correction code.

Moreover, information about encoding methods, e.g., the number ofencryption rounds and erasure coding scheme, can be applied to the datasegment, which is included within related packages.

In storage systems erasure coding module operates with chunks of data.Each chunk can include a number of elements; this number is the same forall chunks. Operations performed on chunks can be parallelized, sincethe same computations should be performed for all elements of a chunk.

An erasure coding scheme can be specified by a generator matrix G of theselected (N, K, D) error-correction code, where N is code length, K iscode dimension and D is minimum distance. Thus, N codeword chunks can beobtained as result of multiplication of K information chunks bygenerator matrix G. Observe that K information chunks may bereconstructed from any subset of codeword chunks of cardinality at leastN−D+1. If a maximum distance separable (MDS) code, e.g., Reed-Solomoncode, is employed, then only K codeword chunks are required forreconstruction of K information chunks. In one or more implementations,such generator matrix G can be selected such that any information chunkcan be reconstructed only from at least s codeword chunks. Parameter sis further referred as a mixing degree. Further, codeword chunks can bedivided into two groups: K mainstream chunks and N−K standby chunks.Here mainstream chunks are given by K codeword chunks, which providelow-complexity recovering of K information chunks.

FIG. 17 is a schematic block diagram illustrating example network loadbalancing for transmission of a group of packages with encoded chunksproduced from related segments. Network load balancing is optimized toreduce latency for READ and WRITE operations. For a specified number ofrelated data segments f 1701, load balancing module 1716 constructs amapping of packages with encoded chunks, produced from f segments, tostorage nodes 1706. More particularly, a set of packages with encodedchunks produced from i'th data segment is mapped to a set of storagenodes, in which 1≤i≤f. Data segments are referred as related ifsimultaneous READ requests for them are predicted. For example, relateddata segments can be data segments produced from the same file (forlarge files) or from files located in the same folder (for small files).At initialization step 1703, index of data segment i is set to zero andan amount of data being transferred, referred as traffic prediction, isalso set to zero. Then, steps 1704 and 1705 are alternately performed,while i<f 1717, i.e., until all of the segments are processed. At step1704, a mapping for i'th data segment is selected in such a way thatweighted load is approximately the same for all storage nodes. Here,load for g'th storage node is estimated as L_(g)=p_(g)+r[M_(i,g)], wherep_(g) is actual traffic prediction for g'th storage node, r[j] isrelevance coefficient for j'th codeword position and M is a mappingmatrix, such that M_(i,g) is codeword position of encoded chunk,produced from i'th data segment and being transmitted to g'th storagenode. In order to guarantee specified level of data protection, for anyfixed i elements, M_(i,g) is different. A weighted load for the g'thstorage node is given by L_(g)/a[g], where a[g] is availabilitycoefficient for g'th storage node. Availability coefficients for storagenodes 1702 and relevance coefficients for codeword positions 1703 areprovided by monitoring module and configuration module, thesecoefficients are periodically updated. At step 1705 traffic predictionis updated according to the mapping for i'th data segment, i.e.,counters of packages for storage nodes are increased.

So, after processing of f segments load for g'th storage node is equalto L_(g)=Σ_(i=1) ^(f)r[M_(i,g)] and it is proposed to select mapping Min such a way that weighted load L_(g)/a[g] is approximately the samefor all storage nodes. Observe that load balancing 1716 can beconsidered as a greedy method, since for i=1, . . . , f local optimum isfound at step 1704. More complex global optimization of matrix M may beperformed simultaneously for all data segments.

Computation of availability coefficients for storage nodes 1709 is basedon system statistics 1707. System statistics is accumulated bymonitoring module, which is distributed across the whole processingsystem. For example, average time between READ request sending moment(to a storage node) and package receiving moment is estimated.Similarly, for WRITE request average time between package sending moment(to a storage node) and acknowledge receiving moment is estimated. Thesetime estimations are referred to herein, generally, as latencyestimations for different requests 1711. Distribution of the number ofrequests over time 1712 is employed to identify groups of almostsimultaneous requests for which network load should be optimized in thefirst place. Amount of transmitted data is measured in the case oftraffic distribution 1713 analysis. The list of statistics, utilized forcomputation of availability coefficients, is not limited by 1711, 1712and 1713, i.e., other available statistics may be also utilized.

Computation of relevance coefficients for codeword positions 1710 isbased on system statistics 1707 and configuration metadata 1708,provided by monitoring module and configuration module, respectively.Configuration metadata 1708 can be represented by erasure coding scheme1715. This is usable to identify codeword positions, which are accessedin the first place upon a READ request. Relevance coefficients 1703 canbe jointly optimized for different request types using probabilities ofdifferent requests 1714. More particularly, probabilities of differentrequests 1714 are employed as weighted coefficients in linearcombination of relevance coefficients optimized for different requests.

In order to minimize latency for READ and WRITE operations, the networkload can be balanced. However, there is also a reliability requirement,such that none of storage nodes may receive more than one element ofeach codeword.

Initialization of load balancer can include computation of relevancecoefficients for codeword elements, in which codewords belong to apre-selected code and computations are based on the analysis ofpre-selected encoding scheme.

FIG. 18 is a schematic illustration of an example server cluster cacheand its respective environment. As noted herein, a server cluster 1801can include a file system server (FSS) 1802 and a number of processingservers (PS) 1803. A cache located within the server cluster 1801 isconsidered as intermediate storage between a set of storage nodes andclient applications. A server cluster cache is further referred as acache. A cache can be divided into a metadata cache 1805 and an objectcache 1804, in which a metadata cache 1805 is usable to store filesystem metadata and an object cache 1804 is used to store objects, e.g.,data segments. In the case of a WRITE request, data from clientapplication is kept in an object cache 1804 prior to transferring tostorage nodes, while in the case of a READ request, data are transferredfrom storage nodes to object cache 1804 and then to the clientapplication. Metadata cache 1805 contains the latest version of a partof file system metadata. A full version of file system metadata isstored within storage nodes, and this full version is periodicallyupdated using partial version from the metadata cache 1805. Differentparts of file system metadata are transferred from storage nodes tometadata cache 1805 on demand.

FIG. 19 illustrates components of an example cache located within eachserver cluster. A cache of a server cluster 1901 may comprise severalstorage devices 1907 and, more particularly, random-access memory (RAM)1905 and a number of solid-state drives (SSD) 1906. Storage devices 1907can be managed by a controller 1904. Cache controller 1904 can providethe following functionality: memory allocation, reading and writing bydata blocks, block status management, free space management, garbagecollection initiation. Request analysis and statistical data processingcan be performed by analyzer 1902. Garbage collector 1903 usesinformation provided by analyzer to select blocks to be deleted, therebyorganizing free space for new blocks.

Cache for objects and cache for file system metadata are describedseparately, due to differing logical structures and functionality.

An object cache can be employed as a data buffer. Data can betransferred by portions, by segments between storage nodes and cache,and by sequences of small blocks between cache and client applications.These small blocks are further referred as r/w blocks, and their sizedepends on client applications. Typically r/w blocks are produced by afile system, designed for block-level storage, so r/w block size is 4KB-512 KB. The segment size corresponds to the block size forobject-level storage. In the case of object-level storage large blocksare desired, such as 1 MB-128 MB. Large blocks can be referred to hereinas compound blocks, since they are obtained from contiguous r/w blocks.Observe that file systems designed for block-level storage are referredas block-based file systems, while file systems designed forobject-level storage are referred as object-based file systems. Thus,data within a cache may be modified by small r/w blocks, while datastored in the cloud (i.e., distributed over storage nodes) may bemodified by compound blocks. Maximum access speed can be achieved ifobjects are kept in a cache as single pieces. In this case, throughputalso increases because of reduced amount of metadata, and the size ofother file system data structures decreases.

In accordance with one or more implementations of the presentapplication, the system operates with compound blocks, and a number ofdifferent sizes for compound blocks may be specified. A compound blocksize for an object can be selected depending on an object size and anobject access pattern. In the case of dominating linear access pattern,large compound blocks may be more efficient, while in the case ofdominating random access pattern, smaller compound blocks may be morepractical. In order to identify parameters for compound block sizeselection, analysis of operations over files, produced by clientapplications, can be performed. For example, file extensions areclustered into a number of categories, depending of dominating accesspattern as result of the analysis. Observe that access pattern is alsouseful for selection of prefetching strategy for a file, where accesspattern is utilized to predict a set of compound blocks to be accessedwith high probability in the near future. Moreover, analysis of filesizes is performed. For example, distribution of the number of fileswith different sizes may be analyzed, as well as distribution of thetotal number of bytes within files with different sizes. The number ofcategories can be specified by a client or selected by the systemautomatically. In a simple case, only one compound block size isselected, so that all objects are divided into compound blocks of thesame size. An obtained table of file extensions with associated compoundblock sizes can be kept as a part of system configuration metadata, andmay be reconfigured upon administrator's request. The choice of compoundblock size depends not only on file extension, but also on other filesattributes, such as size.

FIG. 20 shows an example logical structure of server cluster cache forobjects according to the present invention. Cache logical structurecomprises three levels: storage device level 2003 operating over bytes2007, block-based file system level 2002 operating over r/w blocks 2006,e.g., 4 KB-512 KB, and object-based file system level 2001 operatingover compound blocks 2005, e.g., 1 MB-128 MB, and regions 2004. Memoryspace is divided into regions 2004. Each region 2004 comprises compoundblocks 2005 of selected size, where all compound blocks 2005 within aregion 2004 have the same size. Observe that segment size for an object,is limited by the largest compound block size. Variety of compound blocksizes provides opportunity to keep big objects in contiguous space,while preventing small objects from consuming too much space.

Each compound block has a unique identifier consisting of regionidentifier and local identifier, where local identifier specifiescompound block inside region. Local identifiers are used to trackstatuses of compound blocks within region, as well as to access data.Thus, there can be two bitmaps: free compound blocks bitmap 2009, whichshows whether a particular compound block is free or not, and dirtycompound block bitmap 2010, which shows whether a particular compoundblock is dirty or not. Furthermore, each region has significance map2011, where significance of a compound block depends on the last accesstime and statistics on files stored within the system. Compound blocksof high significance are treated as hot blocks, while blocks of lowsignificance are treated as cold blocks. Map 2011 may be implementedtogether with bitmaps 2009 and 2010 as a status map, or separately frombitmaps.

Each region 2004 has region head 2008 containing region parameterstogether with region summary, where region summary shows the number offree compound blocks within the region, the number of dirty blockswithin the region and other statistics on the region.

A file is stored within one region. A region may contain one file orseveral files. Region size is selected in order to provide fast memoryaccess, easy memory management and minimize the total amount ofmetadata, while avoiding excessive segmentation of memory space. A newregion with specified compound block size is initialized when required.Files are assigned to regions to provide compact data placement, i.e.,to minimize the number of regions being employed. If region containsonly free blocks, then this region is marked as free one, and it may beinitialized for another compound block size.

Data in compound blocks are stored together with corresponding metadata,referred as compound block metadata (CBMD) 2012. CBMD concept is similarto encode data structure in UNIX-style file systems. CBMD containsattributes of related file segment. File segment data 2013 is storednext to CBMD, so there is no need to store compound block locationexplicitly. If all file data segments are stored in a region, then thisregion also contains all necessary metadata to reconstruct the file.Thus, file may be retrieved even if file system metadata is unavailable.File identifier is also stored as a part CBMD. CBMD may also containfree bit, dirty bit and status value, being updated each time whencompound block is accessed.

Compound block size can be selected to balance the followingrequirements: minimization of wasted memory space, minimization of thenumber of compound blocks to be transmitted, implementation simplicity.

It can be seen that these requirements may not be fully satisfiedsimultaneously. Accordingly, a selection of the smallest compound blocksize, i.e., block size used by block-based file system, can be made.However, in this case the number of transmitted blocks appears to beprohibitively high. On the other hand, the number of transmitted blocksmay be minimized by selection of large compound block size, which leadsto transmission of blocks with small amount of relevant data in the caseof small objects. Alternatively, the first and the second requirementscan be satisfied by using diversity of compound block sizes. However, itmay be difficult to predict how many blocks of each size is required toidentify optimal region distribution. Moreover, this approach withdiversity of sizes can hardly be efficiently implemented, and theprobability of block selection mismatch increases (in the case ofsequential READ requests). Thus, typical number of different compoundblock sizes recommended by the system is 1-4.

Observe that a workload may change during lifetime of the system and iflater gathered statistics will show that current division by regions isnot optimal, then parameters of compound block size selection method maybe reconfigured.

Let us consider several scenarios related to creation of a new file,modification of existing one, i.e., downloaded from the cloud (i.e.,storage nodes), and reading of a part of a file.

First we consider a new file creation with subsequent write request.File creation includes generation of corresponding metadata and metadataspreading over server clusters, more particularly, file system servers.File metadata includes file attributes, identifiers (e.g., fileversion), cloud location information (e.g., list of segments), filecoding settings (compression settings, encryption settings, erasurecoding scheme and etc.), file storage settings (e.g., flags for partialupdates, intermediate storage settings) and file statistics (e.g.,timestamps).

Memory allocation policy for a file stored within the processing systemcache is further described. File caching parameters include maximumnumber of compound blocks allocated for a file and a paralleltransferring threshold. R/w block size may be also considered as aparameter, where r/w block size indicates granularity of data writes andreads. Further, parallel transferring threshold is equal to the numberof recently updated (hot) compound blocks which must be sent onlysequentially, other compound blocks of a given file may be sent inparallel. In the case of file opening event a fixed number of compoundblocks is allocated. Compound blocks may be transferred to storage nodesby request or by timeout.

FIG. 21 is a schematic block diagram illustrating example memoryallocation for an object. The amount of allocated memory is given bydata segment size 2101 supplemented by metadata. At step 2102 size ofcompound block is selected from a pre-defined set. At step 2102 compoundblock size equal to specified data segment size 2101 is selected. Atstep 2103 the nearest (fast accessible) region with free compound blocksof required size is selected. Recall that information on free blocks ina region is a part of region summary located in region head. So, thereis no need to scan free CB bitmap. Then a free compound block withinselected region is occupied at step 2105 and its status is changed atstep 2106. Location of compound block 2107 is given by the address ofselected region and address of the compound block within region.

If there is no free compound blocks of the size equal to data segmentsize 2101, then one of the following two strategies is employed. Thefirst strategy consists in a selection of compound block size t-timessmaller than the data segment size 2101, where t is as small as possibleand t such blocks are available. The second strategy consists in oneusing garbage collector to arrange free compound blocks of data segmentsize 2101. However, probability of free compound block absence is verylow, since the processing system performs monitoring of free blocks andgarbage collection on a regular basis.

FIG. 22 is a schematic block diagram illustrating an example removal ofobsolete objects from server cluster cache for objects in order toarrange free space for new objects, this procedure is referred asgarbage collection. Garbage collection comprises three processes: freespace monitoring, relocation process and removal process. The problem ofgarbage identification reduces to estimating probability for eachcompound block to be accessed. Compound blocks marked as garbage arelater deleted. Free space monitoring process, arranged as backgroundprocess, estimates the number of free compound blocks within each regionand analyses segmentation level. Segmentation level of a region dependson location of free compound blocks. More particularly, if free compoundblocks are located in contiguous manner, then segmentation level is low;if almost all free compound blocks are separated by utilized compoundblocks, then segmentation level is high. Depending on segmentation levelestimates, relocation processes may be started.

In order to estimate the number of free compound blocks for a regionfree space monitoring process utilizes region summary, located withinregion head, or scans free compound block bitmap and updates regionsummary. Region summary information is utilized if it was recentlyupdated, otherwise free compound block bitmap is used. The number offree compound blocks in all regions is analyzed depending on compoundblock size. If the number of free compound blocks of a particular sizein initialized regions is lower than a pre-defined threshold, and thereis no memory space to arrange new region, then the removal process isstarted for regions with compound blocks of specified size.

Removal process for a specified compound block size 2201 proceeds asfollows. At first regions with compound blocks of size 2201 areidentified at step 2203. Further steps correspond to separate processingof these regions. Thus, these regions may be processed sequentially orin parallel. In step 2204 information on the last access time for eachutilized compound block within region is accessed. At step 2205significance of each compound block is estimated. In general casesignificances of related compound blocks are jointly computed, sincethese significances depend on distribution of the last access time (forthese related compound blocks) and system statistics 2208. Typicallyrelated compound blocks are given by compound blocks produced from thesame file. Significance computation method is employed with differentparameters for files of different types. Choice of parameters for a filetype mostly depends on data access pattern 2209 dominating for this filetype. Other statistics 2210 may be also utilized. Compound blocks,produced from adjacent data segments of a file, have similarsignificances in the case of dominating linear access pattern, whilethese significances are almost independent in the case of dominatingrandom access pattern. In a simple case, such parameters forsignificance computation method are selected, that joint computationsfor related compound blocks may be reduced to independent computationsfor each compound block. Computed significances are written intocompound block significance map. Steps 2204 and 2205 may be skipped ifcompound blocks significance map was recently updated. At step 2206 lesssignificant compound blocks are removed from server cluster cache forobjects. Observe that compound blocks marked as dirty may not bedeleted.

Metadata can be cached within server clusters. According to one or moreimplementations of the present application, distributed storage systemmay comprise one or several server clusters. There is one file systemserver containing metadata per each server cluster. File system serversstore identical copies of metadata.

FIG. 23 illustrates an example of file representation within thedistributed storage system. Here, only several entities contain originalfile data and metadata, provided by client application. Original filedata is represented by chunks of encoded data segment of the file 2315,while original file metadata is given by file attributes 2303 and it isalso partially kept within package metadata 2314. Other entities areclassified as system metadata, which is relevant only within theobject-based distributed storage system.

File data and metadata are distributed over storage nodes and may berequested using references. A reference can include prefix, type, HASHand identifier. The first part of reference, i.e., prefix, identify aparticular instance of distributed storage system, vault within thesystem and volume within the vault. The second part of reference is typeof the content stored by this reference. Thus, type shows whethercontent is represented by data or metadata, e.g., file root metadata orsegment metadata. Type also shows whether content is related to alogical file, comprising a number of small files, or to a typical file.The third part of reference is HASH of the content stored by thisreference. The fourth part of reference is any identifier, which is ableto guarantee reference uniqueness. This identifier may be randomlygenerated. HASH value is employed for deduplication and for integritycheck. Thus, if some content is duplicated in the system, thencorresponding references contain the same HASH and almost certainly thesame prefix and type. Upon identification of two references, which aredifferent only in the fourth part, content comparison is performed, andin the case of coincidence, one reference is replaced by the second oneand content, related to the first reference, is removed from the system.Observe that it is assumed that there is almost no intersection betweendata stored within different volumes, so deduplication is performedseparately for each volume. For each file there is a special file rootmetadata reference, which does not depend on file content, i.e., it doesnot contain HASH.

Hereinabove a reference is classified as data reference (DR) or metadatareference (MDR). DR is a reference to encoded original data, while MDRis a reference to metadata containing DRs and/or MDRs. MDRs and DRs of afile are arranged into tree, referred as file reference tree. In thisparticular example file reference tree contains three levels, where thefirst level is represented by file root MDR 2301, the second level isrepresented by segment MDRs 2306 and the third level is represented byDRs 2312. In general case the number of levels may be different, whileleaves are always given by DRs. In the case of large files the number oflevels may be increased, while decreased in the case of small files.File root MDR is a special MDR, providing opportunity to iterativelyretrieve all file data and metadata from storage nodes. File root MDR isunique for each file.

File root metadata 2302, accessible by file root MDR 2301, includes fileattributes 2303, file size 2311 and a list of segments, where eachsegment within the list is specified by its index 2304, i.e., positionwithin the file, subset of storage nodes (SSN) 2305 and segment MDR2306. Here indices 2304 are required to recover a file from datasegments. Segment metadata 2307 may be transferred using correspondingsegment MDR 2306 from any storage node belonging to SSN 2305. If segmentmetadata 2307 is t-times replicated, then corresponding SSN 2305includes t storage nodes. Segment metadata 2307 can include segment size2308, segment HASH 2309, codes parameters 2310 and list of packages withencoded chunks, produced from the segment. A location of a package isspecified by DR 2312 and SSN, as in the case of segment metadatalocation. SSN for a package typically consists of one storage node,since data segment is erasure coded and no additional replication isrequired. Index shows a local position of a package with encoded chunk,i.e., the position of encoded chunk within codeword of employederror-correcting code. Erasure coding scheme, e.g., error-correctingcode, encryption method and compression method are specified in encodingparameters 2310. Package 2313, accessible by corresponding DR 2312,includes metadata 2314 and a chunk of encoded data segment of the file2315. Here metadata 2314 may include metadata for the related chunk2315, as well as metadata for the file in general.

FIG. 24 shows an example of logical file metadata. Logical file root MDR2401 is needed for iterative retrieval of logical file together withcorresponding metadata and references from storage nodes. Distributedstorage system operates with logical file root metadata 2402 in the sameway as with file root metadata, represented at FIG. 23. Logical fileroot metadata 2402, stored under reference 2401, can include commonmetadata and separate metadata for each embedded file. Common metadatacomprises attributes of the logical file 2403, being similar toattributes of a typical file, size of the logical file 2404, small filesembedding scheme 2405 and segment MDR 2406. Structure of segmentmetadata, stored under segment MDR 2406, is represented at FIG. 16.Logical file is always packed within one segment, so 2402 contains onlyone segment MDR. Observe that distributed storage system may operatewith segments of different sizes. Size of logical file 2404 should notexceed size of corresponding segment. If such data piece is appended toone of embedded files, that logical file does not fit in the datasegment anymore, then initial logical file may be rearranged into twological/typical files.

Each embedded file is represented within logical file root metadata 2402by file ID 2407, file status 2408, file offset 2409 and file metadata2410. File ID 2407 helps to retrieve data for a particular embeddedfile. File status 2408 shows whether an embedded file is active ordeleted. File offset 2409 shows location of embedded file data withindata segment. File metadata 2410 is metadata of a particular embeddedfile, this metadata is independent of the scheme. If logical file isrearranged, then file metadata 2410 is just copied into a new logicalfile. There are two main reasons for logical file rearrangement: garbagecollection (for embedded files with status “deleted”) and logical filesize exceeding segment size. File metadata 2410 can include fileattributes 2411, file size 2412, file HASH 2413 and encoding parameters2414. Embedded file may be compressed and/or encrypted prior tocombining with other files, wherein this initial encoding is describedby encoding parameters 2414. This means that all steps shown in FIG. 16,except erasure coding 1610, may be individually applied to each embeddedfile, and then the same steps (with another parameters) are applied to adata segment produced from the logical file.

For files stored within the distributed storage system, object-basedfile system keeps a pair given by and including file ID and file rootMDR. Pairs are organized into logical tables and the system can operatewith them as with key-value pairs. Logical tables are arranged as B+tree or another structure designed for efficient data retrieval in ablock-oriented storage context. Frequently used part of logical tablesis cached on the client side, where it arranged as a data structure formaintaining key-value pairs under condition of high insert volume, e.g.,log-structured merge (LSM) tree. Logical tables distributed over storagenodes can be updated by timeout or if the amount of changes exceeds athreshold (i.e., in the case of high workload).

Logical tables can be partitioned into segments, which are encoded intochunks encapsulated into a package and distributed over storage nodes.Erasure coding or replication is employed to guarantee protectionagainst storage nodes failures and to provide high speed retrieval evenin the case of storage node outages. Partition scheme for logical tablesis also packed in encoded chunks encapsulated in packages. Segments oflogical tables are retrieved on demand and cached on the client side.Partition scheme is optimized in order to minimize the number ofpackages being transferred from storage nodes, that is to maximizeprobability that simultaneously needed parts of the tree are packedtogether.

FIG. 25 is a schematic block diagram illustrating an example selectionof a data representation structure for file system management withinserver cluster cache for metadata. Various data structures havedifferent advantages and disadvantages. A data structure can be selectedbased on analysis of a particular distributed storage system.Distribution of the number of requests over time 2505, being a part ofsystem statistics 2501, can be employed by strategy advisor 2503 toidentify predominant operations and operations performed with highfrequency over some periods of time. Traffic distribution over time 2506represents an amount of data processed by the system, when performingvarious operations. Thus, distribution of the number of requests overtime 2505 characterize intensity of various operations, while trafficdistribution over time 2506 characterize their significance. Systeminfrastructure 2502 is also of great importance, so hardwarespecification 2507 is also utilized by strategy advisor 2503. If thenumber of write requests is much higher than the number of readrequests, then LSM tree is an appropriate structure, since it isdesigned specially for the case of intensive insertions. However, searchover LSM tree may not be as fast over a B+ tree, and so smaller latencyfor read operation is provided by B+ tree 2510. A more general datastructure than a tree may be needed in the case of some functionalrequirements, for these cases directed graph 2511, e.g., with cycles, isemployed. There are two types of LSM trees: leveled LSM tree 2508 andsize-tiered LSM tree 2509. Size-tiered LSM tree 2509 is selected only ifwrite operations are performed with excessive intensity, while thenumber of read operations is disparagingly small. Leveled LSM tree withits performance characteristics stands between B+tree and size-tieredLSM tree. Selected strategy 2512 is utilized by object-based file system2514. Efficiency estimates 2513 for the strategy 2512 are provided to becompared with statistical data, which will be further obtained duringsystem lifetime according to selected strategy 2512.

Details and features of the present application directed to erasurecoding is now provided.

Systems and methods to encode data, retrieve and repair data, as well asto distribute data over storage nodes are provided. Proposed methods areoptimized for the needs of cloud storage systems, e.g., security isprovided via information dispersal. High storage efficiency can beprovided by the selected construction of error correcting code. Lowlatency is guaranteed by network load balancing, low complexity encodingand small I/O overhead in the case of repair.

FIG. 26 shows modules of an example system 2601, arranged to executedata encoding and decoding using an error-correcting code. The system2601 comprises five modules, arranged to execute data processing, whichare managed by a control module 2603 according to system configurationprovided by configuration module 2602. Configuration module 2602 keepsspecification of the employed error-correcting code together withencoding and decoding settings. Specification of an error-correctingcode includes at least code parameters; if an error-correcting code isbased on a number of component codes, then the code specification alsocomprises specifications of component codes and their compositionscheme. Fragmentation module 2604 performs partition of original datainto segments. Each segment is processed in an individual manner.Segments may have different sizes or the same size; segment size dependson the system requirements. Encoding module 2605 performs encoding ofsegments with error-correcting code. Chunks of encoded data are assignedto storage nodes by load balancing module 2606 to provide low latencydata retrieval. Retrieval module 2607 performs reconstruction oforiginal data from a sufficient number of encoded chunks, downloadedfrom storage nodes. In the case of storage node failure an old storagenode is replaced by a new one, and repairing module 2608 is employed toreconstruct data within a new storage node.

FIG. 27 is a schematic block diagram illustrating an exampleinterrelationship of modules of a system, arranged to executeerror-correction coding, and environment of the system. Original data2702 is encoded and distributed over storage nodes 2703 by the system2701, as well as retrieved from storage nodes 2703 on demand.

Original data 2702, received by the system 2701, is partitioned intosegments by fragmentation module 2704. Then a number of encoded chunksare generated for each segment by encoding module 2705. Load balancingmodule 2706 generates mapping of encoded chunks to storage nodes, wheremapping is optimized to reduce average latency for segment retrievaloperation. Encoded chunks are further transmitted to storage nodes 2703according to the mapping. Storage nodes 2703 work independently fromeach other and may be located in different areas. Observe that mappingmay be generated by load balancing module 2706 in parallel with dataencoding by module 2705, or mapping generation may be combined withtransmission of encoded chunks to storage nodes 2703.

Upon request, original data 2702 is reconstructed from encoded chunksdistributed over storage nodes 2703 as follows. Load balancing module2706 selects several storage nodes, from which encoded chunks aredownloaded for a particular segment. Retrieval module 2707 performsreconstruction of a segment from a sufficient number of encoded chunks.Observe that in the case maximum distance separable (MDS) codespossibility of data reconstruction does not depend on the positions ofencoded chunks within a codeword; however, the present invention mostlydeals with non-MDS codes, wherein positions of encoding chunks affectdata reconstruction possibility and computational complexity. Obtainedsegments are further combined by fragmentation module 2704 in order torecover original data 2702.

In the case of storage node failure an old storage node is replaced by anew one, and repairing module 2708 is employed to reconstruct datawithin a new storage node. Repairing module 2708 is able to reconstructlost encoded chunks from a sufficient number of available encodedchunks, produced from the same segment.

FIG. 28 shows a flow diagram of example steps executed within encodingmodule 3801. The case of full block encoding is considered. Prior toactual encoding, a block of original data 3802 is divided into K chunksand encoding results in a codeword 3803, consisting of N encoded chunks,where K is dimension of an error-correcting code and N is its length.Chunks of block 3802 and encoded chunks of codeword 3803 have the samesize. During encoding each chunk is considered as a sequence of elementsand eth elements of K chunks of block 3802 are encoded into i'thelements of N chunks of codeword, where element size is defined byerror-correcting code parameters. Thus, computations for elements withdifferent indices are performed in parallel, e.g., using vectorization.For the sake of simplicity, but without loss of generality, descriptionof the invention is given for the case of chunks consisting of a singleelement. Thus, encoding is further described for a block of originaldata 3802, consisting of K elements, and codeword 3803, consisting of Nelements.

High storage efficiency and high erasure correction capability areprovided by the selected construction of error-correcting code, wherestorage efficiency is given by code rate K/N. Error-correcting code ismay be specified by any of its K×N generator matrices. Security isguaranteed by encoding using such generator matrix G, that any chunkwith original data can be reconstructed only from at least s encodedchunks, where s is referred as mixing degree. Thus, even if up to s−1storage nodes are compromised, a malicious adversary will not be able torecover original data.

This approach is implemented as follows. An K×N generator matrix G ofmixing degree s is represented as C=MG^((syst)), where M is K×Knon-singular matrix and G^((syst)) is generator matrix for systematicencoding, i.e., K columns of matrix G^((syst)) constitute identitymatrix, indices of these columns are further referred as systematicpositions. Observe that mixing degree of matrix M is at least s, matrixM is further referred as mixing matrix. Given block of original data3802 x of length K, encoding module computes codeword 3803c=xMG^((syst)). At step 3804 a mixed vector x^((mix)) of length K iscomputed as x^((mix))=xM. Observe the codeword c comprises K elements ofmixed vector x^((mix)), further referred as mainstream elements, whileother N−K codeword elements are computed at step 3805, these N−K arefurther referred as standby elements. At step 3805 Multiplication of themixed vector x^((mix)) by K×(N−K) submatrix R of generator matrixG^((syst)) is performed, wherein submatrix R can include N−K columns atnon-systematic positions.

Codeword elements are classified into mainstream elements and standbyelements in order to arrange low complexity retrieval of original data.More particularly, mixing matrix M is optimized to insure that Koriginal data elements may be reconstructed from K mainstream elementswith low computation complexity. Moreover, if mixing degree s<K andpartial retrieval is supported by the system, then mixing matrix M isfurther optimized to insure that individual original data elements maybe reconstructed from the smallest possible number of mainstreamelements. Observe that this number could not be lower than s. Thus,mainstream elements are requested in priority from storage nodes.

Original data elements are reconstructed from mainstream elements asresult of multiplication by matrix M⁻¹, where M⁻¹ is inverse matrix forM. In order to reduce encoding and retrieval complexity the number ofzeros and units within matrices M and M⁻¹ is maximized. However, thenumber of non-zero elements in each column of matrix M⁻¹ must be atleast s, since matrix M has mixing degree s. Observe that encodingcomplexity depends on complexity of multiplication of a vector by matrixM, while retrieval complexity depends on complexity of multiplication ofa vector by matrix M⁻¹.

A class of mixing matrices of the following structure is introduced forthe case of

$S \leq \frac{K}{2}$M=P ^((left)) SP ^((right)),

where P^((left)) and P^((right)) are K×K permutation matrices, and S isa block-diagonal matrix composed from non-singular matrices S_(i) ofmixing degree at least s, thus

$S = {\begin{pmatrix}S_{0} & 0 & \ldots & 0 \\0 & S_{1} & \ldots & 0 \\\vdots & \vdots & \ddots & \vdots \\0 & 0 & \ldots & S_{v - 1}\end{pmatrix}.}$

So, dimension of each full rank matrix S_(i) is at least s×s.Permutation matrix P^((left)) defines a permutation within original datavector x, while permutation matrix P^((right)) defines a permutationwithin mixed data vector x^((mix)). Inverse matrix S⁻¹ has the samestructure as matrix S, more particularly,

$S^{- 1} = {\begin{pmatrix}S_{0}^{- 1} & 0 & \ldots & 0 \\0 & S_{1}^{- 1} & \ldots & 0 \\\vdots & \vdots & \ddots & \vdots \\0 & 0 & \ldots & S_{v - 1}^{- 1}\end{pmatrix}.}$

In the case of cloud storage systems it is particularly important toreduce network load. If the number of original data elements to bewritten is equal to K, i.e., full block write operation, then the numberof encoded chunks transferred to storage nodes is always equal to thelength N of an error-correcting code. If a whole block of original dataneeded to be recovered, then the number of encoded chunks transferredfrom storage nodes is lower bounded by K. However, in the case ofpartial write/read operations it is possible to provide much lowernetwork load, than in the case of full block write/read operations.Thus, in the case of partial write operation network load is reduced dueto block-diagonal structure of matrix S. Similarly, for partial readoperation network load is reduced due to block-diagonal structure ofmatrix S⁻¹. For example, if only elements of original data correspondingto matrix S_(i) are written, then the number of codeword elements to beupdated is upper bounded by the sum of the number of standby elementsand dimension of matrix S_(i). In order to retrieve elements of originaldata corresponding to matrix S_(i) it is sufficient to download fromstorage nodes mainstream elements corresponding to matrix S_(i).

Moreover, block-diagonal structure of matrices S and S⁻¹ insures lowcomputational complexity for encoding and retrieval of original data.

FIG. 29 is a schematic block diagram illustrating design of anerror-correcting code according to an example implementation of thepresent application. Specifications of the error-correcting code andcorresponding mixing matrix are further utilized by other modules of thesystem.

Error-correcting code being employed is an (N=nt, K, D) linear blockcode C over Galua field GF(2^(m)), where code length N is the number ofelements in codeword vector and code dimension K is the number ofelements in the data vector and minimum distance D is the smallestnumber of positions in which two codewords of code C are different.Configuration module 2901 receives code dimension K and code length N≥Kas input arguments 2902. An (N=nt, K, D) error-correcting code C isconstructed by configuration module 2901 as follows. Code C comprises anumber of component codes, wherein component codes are classified intotwo categories: outer codes and inner codes. Lengths of outer codes aredivisible by n, while inner codes have the same length t. Structure ofcode C is such that decoding in code C reduces to decoding in itscomponent codes. For example, any single erasure may be recovered in acode of length t, so values of no more than t−1 elements are required.Particular values of n and t may be received as input arguments 2902together with N and K, or selected by the configuration module 2901 atstep 2904 together with length multipliers b₀, . . . , b_(h−1), where his the number of outer codes. Lengths of h outer codes are given by nb₀,. . . , nb_(h−1).

At step 2905 a set of nested inner codes is selected, wherein minimumdistances of inner codes are maximized. All inner codes in the set havelength t. Dimension of inner codes is upper bounded by u=Σ_(i=0)^(h−1)b_(i). First of all, (t, u, w₀) linear code C₀ ^((inner)) isselected as inner code with the highest dimension, wherein minimumdistance w₀. Then, such generator matrix G₀ ^((inner)) for the code C₀^((inner)) is selected, that minimum distances of codes generated bymatrices G_(i) ^((inner)) have the highest possible minimum distancesw_(i), where G_(i) ^((inner)) is a matrix consisting of the last Σ_(j=i)^(h−1)b_(i) rows of matrix G₀ ^((inner)), 0≤i<h. For example, maximumdistance separable (MDS) code, e.g., Reed-Solomon code, or binary linearcode can be selected as code C₀ ^((inner)). Observe that only code C₀^((inner)) will be employed for encoding, while the whole set of innercodes is utilized for data retrieval and repair.

At step 2906 outer codes C_(i) ^((outer)) are selected, where 0≤i<h andh is such that Σ_(i=0) ^(h−1)b_(i)=u. Codes C_(i) ^((outer)) have suchparameters (b_(i)n, k_(i), d_(i)), that

${\frac{k_{0}}{b_{0}} \leq \frac{k_{1}}{b_{1}} \leq \ldots \leq \frac{k_{h - 1}}{b_{h - 1}}},$

Σ_(i=0) ^(h−1)k_(i)=K and minimum distance D of code C is maximized, aswell as minimum distances d_(i), 0≤i<h. Reed-Solomon codes or other MDScodes can be employed as outer codes C_(i) ^((outer)). Observe thatcondition Σ_(i=0) ^(h−1)k_(i)=K is needed to ensure required totaldimension K. Further generator matrices in systematic form G_(i)^((outer)) are selected for outer codes C_(i) ^((outer)), 0≤i<h.

At step 2907 code C is specified by its generator matrix G^((init))obtained from matrices G₀ ^((inner)) and G_(i) ^((outer)), 0≤i<u, asfollows. First, K×un matrix G^((outer)) is constructed from k_(i)×b_(i)nmatrices G_(i) ^((outer)), 0≤i<h

$G^{({outer})} = {\begin{pmatrix}G_{0}^{({outer})} & 0 & \ldots & 0 \\0 & G_{1}^{({outer})} & \ldots & 0 \\\vdots & \vdots & \ddots & \vdots \\0 & 0 & \ldots & G_{h - 1}^{({outer})}\end{pmatrix}.}$

Observe that the number of columns of each matrix G_(i) ^((outer)) ismultiple of n, 0≤i <h, and parameters of contiguous matrices G_(i)^((outer)) and G_(i+1) ^((outer)) are such, that

$\frac{k_{i}}{k_{i + 1}} \leq {\frac{b_{i}}{b_{i + 1}}.}$

Second, matrix G^((inner))=G₀ ^((inner))⊗U^((n×n)) is computed, whereU^((n×n)) is n×n matrix consisting of units and ⊗ denotes Kroneckerproduct. Since G₀ ^((inner)) is u×t matrix, matrix G^((inner)) has unrows and tn columns. Third, K×N generator matrix G^((init)) is computedas G^((init))=G^((outer))·G^((inner)), where N=tn. Observe that matrixG^((outer)) depends only on selected outer codes, while matrixG^((inner)) depends only on selected inner codes.

At step 2908 systematic generator matrix G^((syst)) is obtained fromG^((inner)). More particularly, linear operations over rows of K×Nmatrix G^((inner)) are employed in order to obtain K×N matrix G^((syst))comprising K×K identity matrix. According to one implementation,Gaussian elimination is utilized.

At step 2909 generator matrix G=MG^((syst)) is computed, where selectedmixing matrix M is such that any element of vector x can bereconstructed only from at least s elements of codeword c=xG. Generatormatrix G specifies encoding scheme for designed error-correcting code Cof dimension K and length N.

Obtained generator matrix G, comprising mixing matrix M as submatrix, isfurther utilized by encoding module 2912, retrieval module 2913 and loadbalancing module 2914. Generator matrix G^((init)) together withgenerator matrices for inner and outer codes are utilized by repairingmodule 2911, wherein repairing module 2911 performs recovering ofcodeword elements by decoding in code C assuming that generator matrixG^((init)) was used for encoding. All code specifications 2910 are alsostored within configuration module.

According to one implementation, minimum distance of inner codes is atleast 2. So, inner code C₀ ^((inner)) is able to recover at least oneerasure. From the structure of matrix G^((init)) it can be seen, that acodeword c of the code C can include n codewords of (t, u<t, w₀≥2) codeC₀ ^((inner)), so any element c_(i) can be expressed as a linearcombination of at most t−1 other elements c_(j), 0≤j<N, 0≤i<N. Thus, anyerased codeword element may be locally decoded using at most t−1 othercodeword elements, provided that their values are available.

Observe that if all length multipliers b_(i) are equal to one, then theproposed construction code C reduces to an instance of generalizedconcatenated code with outer codes of length n and inner codes of lengtht. On the other hand, if the number of outer codes h is equal to one,then there is one outer code of length nb₀ and one inner code ofdimension u=1, and the proposed construction of code C reduces to aninstance of regenerating code.

Computation of generator matrix in systematic form G^((syst)) fromgenerator matrix G^((init)), performed at step 2908, is furtherdescribed in more details. Recall, that a×b matrix is referred as amatrix in systematic form when it contains a×a identity matrix as asubmatrix, a≤b, and a set of column indices containing this submatrix isreferred as a set of systematic positions. It is assumed that thegenerator matrices G_(i) ^((outer)), 0≤i<h, are in the systematic formwith the set of systematic positions A_(i) ^((outer)) ⊆ {0, 1, . . . ,b_(i)n−1}, |A_(i) ^((outer))|=k_(i), satisfying the followingconditions:

A_(i,0) ^((outer)) ⊆ A_(i,1) ^((outer)) ⊆ . . . ⊆ A_(i,b) _(i) ⁻¹^((outer))where A_(i,j) ^((outer))={a ∈ A_(i) ^((outer))|jn≤a<(j+1)n};

A_(0,0) ^((outer)) ⊆ A_(0,b) ₀ ⁻¹ ^((outer)) ⊆A_(1,0) ^((outer)) ⊆A_(1,b) ₁ ⁻¹ ^((outer)) ⊆ . . . ⊆ A_(h−1,0) ^((outer)) ⊆A_(h−1,b) _(h−1)⁻¹ ^((outer)).

Let A₀ ^((inner)) be a some set of systematic positions for the code C₀^((inner)), then for the code C there exists a generator matrixG^((syst)) with systematic positions A={a+nâ|a ∈ A_(i) ^((outer)),â=Σ_(j=0) ^(i−1)b_(i) and â ∈ A₀ ^((inner))}. Given set of systematicpositions A₀ ^((inner)) for the code C₀ ^((inner)), correspondingsystematic generator matrix G₀ ^((inner,syst)) may be obtained as G₀^((inner,syst))=L^((inner))·G₀ ^((inner)), wherein L^((inner)) is anon-singular matrix. Then G^((syst))=L·G^((init)), wherein a K×K matrixL is obtained from matrix L^((inner)) by substituting L^((inner)) [i,j]·Q^((i,j)) instead of L^((inner)) [i,j], where B[i, j] is j'th elementof i'th row of matrix B and Q^((i,j)) is s_(i)×s_(j) binary matrix, suchthat Q^((i, j)) [g,j]=1 for g+in ∈ A and Q^((i, j) [g, j]=0, otherwise,where s_(i)=|{a ∈ A|in≤a<(i+1)n}|.

FIG. 30 shows a flow diagram of steps executed within encoding module inthe case of system supporting both full block WRITE and part block WRITErequests. Upon receiving WRITE request with full/partial block oforiginal data 3002, encoding module 3001 selects encoding strategy. If afull block is received, the only possible strategy is full blockencoding, comprising data mixing step 3005 and redundancy computationstep 3006. An output of step 3006 is a whole codeword 3003. If a part ofblock is received, then choice of strategy 3007 is made depending on thenumber of original data elements within partial block and theirpositions. More particularly, a strategy at step 3007 is selected tominimize network traffic, i.e., the number of encoded chunks beingtransferred between storage nodes and client side. Minimization ofnetwork traffic is crucial for cloud storage; however, computationalcomplexity may be also taken into consideration. If full block encodingstrategy appears to be more efficient, then missing elements of thepartial block are reconstructed at step 3008. If partial block encodingstrategy is more preferable, then at step 3009 difference betweenreceived partial block and the initial one is encoded and the initialcodeword is updated according to encoding result, wherein the initialcodeword is downloaded from storage nodes and the initial block oforiginal data is reconstructed from the initial codeword. An output ofstep 3009 is a partial codeword 3003.

FIG. 31 shows a flow diagram of steps executed to update a few elementswithin a block of original data, wherein partial encoding 3101 isemployed in order to update codeword elements. Encoding 3101 of partialblock of original data 3102 results in partial codeword 3103. At step3104 difference x^((XOR)) between input partial block of original data3102 x^((new)) and obsolete values of the same elements x^((old)) 3107is computed as x^((XOR))=x^((old)) ⊕ x^((new)). Obsolete elements of theblock 3107 x^((old)) may be recovered on demand; however, their valuesare usually pre-fetched by the system. At step 3105 encoding of blockdifferences x^((XOR)) is performed in order to obtain codeworddifference c^((XOR))=x^((XOR))G. Recall that structure of the generatormatrix G of selected error-correcting code is such, that if vectorx^((XOR)) contains only a few non-zero elements, then the obtainedvector c^((XOR)) also contains only a few non-zero elements. Partialblock encoding is employed only to update a few elements within a block,so original data difference vector x^((XOR)) always contains only a fewnon-zero elements. Thus, the number of codeword elements to be updatedand further transmitted to storage nodes is small. At step 3106 newvalues of codeword elements c^((new)) are obtained from obsoletecodeword elements 3108 c^((old)) and codeword difference c^((XOR)).Since error-correcting code C is a linear block code, new values ofelements are computed as c^((new))=c^((old)) ⊕ c^((XOR)). Here obsoletecodeword c^((old)) corresponds to obsolete original data x^((old)),i.e., they are related by c^((old))=x^((old))G. Observe that ifc^((old)) was not pre-fetched from storage nodes, than it is sufficientto request codeword elements c_(j) ^((old)), where i is such that c_(j)^((XOR)) ≠ 0, and then transmit to storage nodes c_(j) ^((new))=c_(j)^((old)) ⊕ c_(j) ^((XOR)), 0≤j<N. The number of codeword elements to beupdated is given by |{G[supp(x^((XOR))),j] ≠ 0|0≤j<N}|, where supp(z) isthe set of indices of non-zero elements of vector z. Thus, in order toupdate a few original data elements it is unnecessary to performencoding of a full block of original data and transmit all N elements ofobtained codeword to storage nodes.

FIG. 32 is a schematic block diagram illustrating initialization of loadbalancing module and steps performed to map encoded data to storagenodes.

In order to minimize latency for READ and WRITE operations one need tobalance load for storage nodes according to available network bandwidth.However, due to reliability requirement none of storage nodes mayreceive more than one element of each codeword. Load balancing module3201 can include two components, wherein the first component performsinitialization 3202 and the second component computes mapping 3203.

Initialization of load balancing module 3201 consists in computation ofrelevance coefficients 3205 for N positions of codeword elements,wherein codewords belongs to a pre-selected (N,K) error-correcting codeand computations are based on the analysis of pre-selected encodingscheme 3204 for this code.

Initialization component 3202 receives encoding scheme 3204, e.g.,generator matrix G of the pre-selected code, as input argument.

At step 3206 relative average number of WRITE requests δ^((WRITE)) iscomputed for each codeword element c_(i)

${{\delta^{({WRITE})}(i)} = {{P^{({{full}\mspace{11mu} {WRITE}})} \cdot 1} + {P^{({{part}\mspace{11mu} {WRITE}})}\frac{{wt}\left( {G\left\lbrack {- {,i}} \right\rbrack} \right)}{K}}}},{0 \leq i < N},$

where P^((full WRITE)) is probability of full block WRITE operation,P^((part WRITE)) is probability of part block WRITE operation and wt(G[-, i]) is the number of non-zero elements within i-th column of K×Ngenerator matrix G.

In particular, if only full block WRITE requests are supported by thesystem, then P^((part WRITE))=0 and relative average number of WRITErequests is the same for all codeword elements.

At step 3207 relative average number of READ requests δ^((READ)) iscomputed for each codeword element c_(i)

${\delta^{({READ})}(i)} = \left\{ {{{\begin{matrix}\left( {1 - P^{({repair})}} \right. & \left( {{P^{({{full}\mspace{11mu} {READ}})} \cdot 1} + {P^{({{part}\mspace{11mu} {READ}})}\frac{{wt}\left( {M^{- 1}\left\lbrack {- {,m_{i}}} \right\rbrack} \right)}{K}}} \right) \\{{P^{({repair})} \cdot {\theta (i)}},} & {{i \in {\left\{ {0,\ldots \mspace{14mu},{N - 1}} \right\} \backslash A}},}\end{matrix}.\mspace{11mu} i} \in A},} \right.$

where P^((full READ)) is probability of full block READ operation,P^((part READ)) is probability of part block READ operation,P^((repair)) is probability that READ operation that READ operationperformed for the purpose of repair (in a view of storage node failureor unavailability), θ(i) shows average utilization of i'th codewordelement in the case of repair, A is the set of K codeword elements,which are employed for low-complexity reconstruction of original data,i.e., data retrieval when corresponding storage nodes are available. Theset of codewords elements c_(i) with i ∈ A is referred as mainstreamgroup, while the set of other codeword elements is referred as standbygroup. K×K matrix M can include columns of matrix G corresponding tomainstream elements, i.e., G_(-,i) with i ∈ A. Here m_(i)=|{j ∈ A|j<i}|and wt(M⁻¹[-, m_(i)]) is the number of non-zero elements within m_(i)'thcolumn of inverse matrix to matrix M. Observe that (1−P^((repair))) isthe probability of READ operation for the purpose of informationretrieval when storage nodes corresponding to elements of mainstreamgroup are available.

In particular, if only full block READ requests are supported by thesystem, then P^((part READ))=0 and relative average number of READrequest is the same for all elements of mainstream group.

At step 3208 relevance coefficient φ(i) is computed for each codewordelement c_(i) based on the relative average numbers of READ requestsδ^((READ))(i) and WRITE requests δ^((WRITE))(i)

φ(i)=ρ^((WRITE))δ^((WRITE))(i)+ρ^((READ))δ^((READ))(i), 0≤i<N,

where coefficients ρ^((WRITE)) and ρ^((READ)) show cost of WRITE andREAD operations, respectively.

Output of initialization component 3202 is given by relevancecoefficients φ(i) 3205 for codeword elements c_(i), 0≤i<N, which arepassed to mapping component 3203.

Mapping component 3203 receives a number ϕ of related codewords 3209 andtransmission schedule 3211 as input arguments, while relevancecoefficients 3205 and availability coefficients for storage nodes 3210are received as input parameters. Thus, mapping component 3203 executecomputations each time, when a number of related codewords 3209 andtransmission schedule 3211 are received. Transmission schedule 3211 isoptional, by default it is equal to zero. Two codewords are referred asrelated if READ request is predicted to be for both of themsimultaneously, e.g., codewords produced from the same file.Availability coefficients for storage nodes 3210 are based on thebandwidth information and traffic prediction, e.g., average latencyestimation in the case of WRITE and READ requests.

At step 3212 for each storage node initial network traffic τ(i) ispredicted based on transmission schedule 3211. At step 3213 φ×N mappingmatrix μ is optimized. Here 0 x N matrix is referred as mapping matrixif each of its rows is given by some permutation of vector (0, 1, . . ., N−1). Given mapping matrix μ, traffic induced by ϕ codewords isestimated for i'th storage node as Φ(i)=Σ_(j=0) ^(ϕ−1)φ(μ[j, i]). Thus,traffic prediction for i'th storage node is given by τ(i)+Φ(i), whereτ(i) is initial network traffic prediction for the i'th storage node.Optimization of mapping matrix μ consists in selection of suchpermutations, that

${\frac{{\tau (0)} + {\Phi (0)}}{\alpha_{0}} \approx \ldots \approx \frac{{\tau \left( {n - 1} \right)} + {\Phi \left( {n - 1} \right)}}{\alpha_{n - 1}}},$

where α_(i) is availability coefficient for the i'th storage node.

Optimized ϕ×N mapping matrix μ specifies mapping of codeword elements tostorage nodes, wherein a set of codeword elements assigned to the g'thstorage node is given by elements c_(μ[j,g]) ^((j)), 0≤j<ϕ, where c_(t)^((j)) is the t'th element of the j'th codeword.

Let us describe how original data can be reconstructed from codewordelements distributed over storage nodes. Most of the time all storagenodes are available and original data x can be easily reconstructed fromcodeword elements of mainstream group. More particularly,x=c^((main))S⁻¹, where c^((main)) is a codeword subvector consisting ofc_(i), i ∈ A, and S⁻¹ is inverse matrix to matrix S. Since matrix S isblock-diagonal matrix, S⁻¹ is also block-diagonal matrix:

${S^{- 1} = \begin{pmatrix}S_{0}^{- 1} & 0 & \ldots & 0 \\0 & S_{1}^{- 1} & \ldots & 0 \\\vdots & \vdots & \ddots & \vdots \\0 & 0 & \ldots & S_{v - 1}^{- 1}\end{pmatrix}},$

where S_(g) ⁻¹ is inverse matrix to matrix S_(g), 0≤g<v. Since eachmatrix S_(g) specifies a linked subset L_(g) of mainstream group, suchthat c^((main))[L_(g)]=x[L_(g)]S_(g), original data can be reconstructedas x[L_(g)]=c^((main))[L_(g)]S_(g) ⁻¹, 0≤g<v. Observe that cardinalityof the set L_(g) is equal to the dimension of matrix S_(g). If onlyx_(j), j ∈ L_(g), is required then it can be computed as

x _(j) =c ^((main))[L _(g)]S _(g) ⁻¹[-, r],

where r=j−Σ_(i=0) ^(g)|L_(g)| and B[-,i] is the i'th column of matrix B.

This expression is employed in the case of full block data retrieval, aswell as in the case of partial data retrieval.

Thus, if some elements x_(j) of original data are required, then

Corresponding linked subsets L_(g) are identified;

Elements of mainstream group, belonging to identified linked subsetsL_(g), are requested from storage nodes;

Required elements of original data are computed:x_(j)=c^((main))[L_(g)]S_(g) ⁻¹[-, r].

FIG. 33 shows flow diagram of example steps executed within repairingmodule for reconstruction of erased elements of encoded data. In thecase of storage node failure an old storage node is replaced by a newone, and repairing module 3301 is employed to reconstruct data within anew storage node. Moreover, repairing module 3301 is also employed, whenrequired element of original data cannot be reconstructed from elementsof mainstream group, since some of them are unavailable due to storagenode outage. In both cases these unavailable codeword elements arereferred as erased elements. Positions of erased elements withincodeword constitute erasure configuration e: e_(i)=1 if i'th codewordelement is erased and e_(i)=0, otherwise, 0≤i<N. It is assumed thaterasure configuration is known prior to repair, but values of codewordelements are unknown.

Repairing module 3301 receives erasure configuration 3302 as inputargument. Repairing module 3301 compute values of erased elements 3303and adjusted erasure configuration 3304 as follows. At step 3305 repairschedule is constructed. Within step 3305 all operations are performedover erasure configurations, thus actual values of elements are notrequired. Repair schedule designed to minimize the number of codewordelements to be transmitted from storage nodes. Repair schedule comprisesspecification of operations to be performed over non-erased codewordelements in order to obtain values of erased codeword elements. Repairschedule also contains list of positions of employed non-erasedelements. Codeword elements are requested according to this list fromstorage nodes at step 3306. If all requested codeword elements arereceived 3307, then values of erased codeword elements are computedaccording to the repair schedule at step 3308. However, if not allrequired codeword elements were received within a time limit, then atstep 3309 erasure configuration is adjusted by appending to it positionsof requested but not received codeword elements. Adjusted erasureconfiguration 3310 is employed to design a new schedule at step 3305.

FIG. 34 shows flow diagram of attempts to recover codeword elementsusing different strategies in accordance with one or moreimplementations. According to the present invention one of three repairstrategies is selected. These strategies are referred as single-stagerepair, multi-stage repair and massive repair. Choice of strategydepends on the number of erasures and structure of erasureconfiguration. Single-stage repair has the lowest complexity and it isthe most commonly used one. Multi-stage repair include single-stagerepair as the first step. Massive repair is used only in the case ofsingle-stage and multi-stage repair failures, since its complexity ishigher than complexity of multi-stage repair.

Output of repair schedule design 3401 is given by repair schedule 3403,constructed to recover erasure configuration 3402. At step 3404 anattempt to recover erased elements within single-stage repair strategyis made. If repair schedule was successfully 3405 designed at step 3404,then this schedule is returned as output repair schedule 3403. Ifsingle-stage repair failed to recover all erasures, then an attempt torecover them within multi-stage repair is made at step 3406. Uponsuccess, multi-stage repair schedule is returned as output repairschedule 3403, otherwise repair schedule 3403 is designed according tomassive repair strategy 3408.

FIG. 35 shows flow diagram of repairing steps corresponding tosingle-stage repair strategy. Single-stage repair schedule module 3501receives erasure configuration 3502 as input argument. Any erasureconfiguration containing up to w₀−1 erasures is recoverable bysingle-stage repair, where w₀ is the minimum distance of inner code C₀^((inner)). Erasure configurations containing more than (t−u)n erasurescould not be recovered with single-stage repair, so such erasureconfigurations are passed to multi-stage repair schedule module. If thenumber of erasures is between w₀ and (t−u)n, then there is possibilitythat this erasure configuration may be recovered by single stage repair.

Recall that it is possible to identify sets T₀, . . . , T_(m−1)consisting of t elements, such that codeword c of the error-correctingcode C can include n codewords c[T_(j)] of the (t, u, w₀) code C₀^((inner)), 0≤j<n; and also recall, that the code C₀ ^((inner)) is ableto correct up to w₀−1 erasures. At step 3504 single-stage repairperforms recovering of erased elements within each codeword c[T_(j)]independently. Thus, if the number of erased elements within c[T_(j)] isless than the minimum distance w₀, 0≤j<n, then there exists asingle-stage repair schedule to reconstruct all erased elements. Thereis possibility that up to t−u erasures may be recovered within c[T_(j)].If all erasures are reparable 3505, the single stage repair schedulemodule 3501 declares success and returns repair schedule 3503.Single-stage repair schedule 3503 is such that for each erased elementc_(g), g ∈ T_(j), it comprises a representation of c_(g) as a linearcombination of non-erased elements of c[T_(j)]. If there are someunrecoverable erasures, single-stage repair schedule module 3501declares failure and passes erasure configuration 3502 to multi-stagerepair module.

FIG. 36 shows a flow diagram of repairing steps corresponding tomulti-stage repair strategy. Operations are performed over elements ofcodeword c and elements of temporary vector y, where c is codeword oferror-correcting code C and temporary vector y is such thatc[T_(j)]=y[T_(j)]G₀ ^((inner)), 0≤j<n. Elements of c and y are treatedas variables with unknown values. Positions of erasures within codewordc are given by erasure configuration e 3602, received by the multi-stageschedule module 3601 as an input argument. Temporary erasureconfiguration e is related to the vector y. Actual repair stage is shownby variable i, which is initially assigned to zero at step 3604.Multi-stage repair proceeds as follows.

At step 3605 reconstruction of first b_(i) information elements forcodewords of the code C_(i) ^((inner)) is performed as follows. Each ofn codewords of an inner code is processed individually. For j'thcodeword of an inner code elements y_(g) are expressed via elementsc_(p) whether it is possible, where g ∈ T_(j) ∩ A_(i) ^((outer)), 0≤j<nand p ∈ T_(j) is such that e_(p)=0. Successfully expressed elementsy_(g) are marked as recovered, i.e., ê_(g)←0, otherwise marked aserased, i.e., ê_(g)←1. Observe that |T_(j) ∩ A_(i) ^((outer))|=b_(i).

At step 3606 erased elements within codewords of the code C_(i)^((outer)) are repaired. Thus, each erased element y_(g) is expressedvia non-erased elements y_(p), where g ∈ A_(i) ^((outer)) is such thatê_(g)=1, and p ∈ A_(i) ^((outer)) is such that ê_(p)=0. On success eachelement y_(g) is marked as recovered ê_(g)←0.

If each element y_(g) was successfully recovered at step 3606, i.e.,ê_(g)=0 for all g ∈ A_(i) ^((outer)), then at step 3607 a decision ismade to proceed with step 3609. Otherwise, failure of multi-stage repairis declared at step 3608 and proceed with the massive repair scheduledesign.

At step 3609 erased elements within codewords of the inner code C_(i)^((inner)) are repaired. Each of n codewords of an inner code isprocessed individually. Each erased element c_(g) is expressed vianon-erased elements c_(p) whether it is possible, g ∈ T_(j) is such thate_(g)=1, and p ∈ T_(j) is such that e_(p)=0, 0≤g<N. Successfullyexpressed elements c_(g) are marked as recovered, i.e., e_(g)←0.

If all erasures within erasure configuration 3602 are repaired prior tostep 3610, i.e., e_(g)=0 for all 0≤g<N, then obtained multi-stage repairschedule is returned as output repair schedule 3603. Otherwise, stageindex is increased i←i+1 3611 and multi-stage repair schedule designproceeds with step 3605.

Massive repair schedule module receives erasure configuration as inputargument. Error correction capability of massive repair is limited onlyby code construction. Thus, any erasure configuration containing lessthan D erasures is recoverable by massive repair, where D is the minimumdistance of error-correcting code C. If the number of erasures isbetween D and N−K, then there is possibility that this erasureconfiguration may be recovered by massive stage repair. Observe that inthe case of MDS codes values of N−K is equal to D−1; however,error-correcting code C does not belong to MDS codes. Massive repair canbe implemented in several ways.

First, in the case of short codes it is possible to keep list of paritychecks for a code. Observe that if one parity check comprises allcodeword elements of another parity check, then there is no need to keepthe first parity check. Repair using parity checks is performed asfollows. In order to repair g codeword elements, such group of g paritychecks is selected, that i'th erased codeword element participates onlyin the i'th parity check from Π^((g)), and the total number of differentcodeword elements participating in parity checks of Π^((g)) isminimized. The second condition corresponds to minimization of thenumber of READ requests. Alternatively, instead of the second conditionone can optimize Π^((g)) to reduce latency. For that Π^((g)) consistingof highly available codeword elements is selected, where highlyavailable elements are elements which can be quickly transferred fromstorage nodes or cached elements. Repair with parity checks may beutilized for components codes of the error-correcting code C.

Second, in the case of long codes massive repair, based on Gaussianelimination, can be employed. It proceeds as follows. At first step Knon-erased highly available codeword elements Ω are selected, whereinelements Ω are such that corresponding columns of generator matrix arelinearly independent. Thus, latency is minimized. Observe that thenumber of READ requests is equal to K. At the second step matrix Γ isconstructed from columns of generator matrix corresponding to elements Ωand g columns corresponding to elements being repaired. At the thirdstep Gaussian elimination is applied to rows of matrix Γ in order toobtain matrix in systematic form, wherein systematic positionscorrespond to elements Ω. Values of elements being repaired are obtainedby multiplication of sequence of elements Ω by non-systematic part ofmatrix Γ.

If a code of arbitrary length is required, then puncturing andshortening may be applied to the (N=nt, K, D) code C in order to obtaina code of length {circumflex over (N)}<N.

The application is now further described in connection with thefollowing points.

Point 1. A method for distributing data of a plurality of files over aplurality of respective remote storage nodes, the method comprising:

splitting into segments, by at least one processor configured to executecode stored in non-transitory processor readable media, the data of theplurality of files;

encoding, by the at least one processor, each segment into a number ofcodeword chunks, wherein each codeword chunk together with encodingparameters and identifiers constitute a package, and codeword chunks donot contain any piece of the original segment;

generating, by the at least one processor, metadata for at least onefile of the plurality of files and metadata for related segments of theat least one file, wherein the metadata for the at least one filecontains information to reconstruct the at least one file from thesegments, and metadata for the related segments contains information forreconstructing the related segments from corresponding packages;

encoding, by the at least one processor, the metadata into package,wherein the encoding corresponds to a respective security level and aprotection against storage node failure; assigning, by the at least oneprocessor, packages to remote storage nodes, wherein the step ofassigning corresponds to optimized workload distribution as a functionof available network bandwidth;

transmitting, by the at least one processor, each of the packages to atleast one respective storage node; and

retrieving, by the at least one processor, at least one of the pluralityof files, as a function iteratively accessing and retrieving packages ofmetadata and file data.

Point 2. The method of point 1, wherein the step of data splittingprovides data within a respective segment that comprises a part of oneindividual file or several files.

Point 3. The method of point 2, further comprising aggregating aplurality of files for a segment as a function of minimizing adifference between segment size and a total size of embedded files, anda likelihood of joint retrieval of embedded files.

Point 4. The method of point 1, wherein the step of file segmentencoding includes deduplication as a function of hash-based features ofthe file.

Point 5. The method of point 1, wherein the step of segment encodingincludes encryption, wherein at least one segment is encrypted entirelywith an individual encryption key.

Point 6. The method of point 1, wherein the step of segment encodingincludes encryption, wherein at least one segment is partitioned into anumber of pieces, and each piece is separately encrypted, wherein anumber of encryption keys per segment ranges from one to the number ofpieces.

Point 7. The method of point 5 or 6, wherein the encryption key isgenerated as a function of data being encrypted and random data;

Point 8. The method of point 5 or 6, wherein individual encryption keysfor segments are encrypted with a key encryption key and distributedover respective storage nodes, wherein the key encryption key isgenerated using a password-based key derivation function.

Point 9. The method of point 1, wherein the step of segment encodingcomprises erasure coding of mixing degree s, where codeword chunks areproduced from information chunks using a linear block error correctioncode and mixing degree s indicates that at least s codeword chunks arerequired to reconstruct any information chunk.

Point 10. The method of point 9, wherein respective erasure codingtechniques are selected for data segment encoding and metadata encoding,such that metadata is protected from at least the same number of storagenode failures as corresponding data segment.

Point 11. The method of point 1, wherein the step of assigning ofpackages to remote storage nodes minimizes retrieval latency for a groupof related segments.

Point 12. The method of point 11, wherein retrieval latency is minimizedas a function of at least statistical data used to compute availabilitycoefficients for storage nodes, wherein an availability coefficientcharacterizes predicted average download speed and its fluctuations forrespective storage node.

Point 13. The method of point 12, wherein retrieval latency is minimizedas a function of at least availability coefficients for storage nodesand relevance coefficients for codeword positions, wherein a relevancecoefficient is a function of information representing an employederasure correction coding scheme and significance of the respectivecodeword position for data retrieval.

Point 14. The method of point 1, wherein general metadata for a file andindividual metadata for related segments is divided into two parts, inwhich one part is individually packed in packages and another part isappended to packages containing respective encoded data segments.

Point 15. The method of point 1, wherein the files distributed overremote storage nodes are managed by an object-based file system that isdistributed over remote storage nodes and at least partially cached on aclient storage devices.

Point 16. The method of point 15, further comprising selecting a treerepresentation for a locally cached part of a file system, where thechoice is based on a request analysis and a hardware specification, andalternatives are given by a log-structured merge-tree, B+ tree or adirected graph.

Point 17. The method of point 16, wherein a file system tree maintainsreferences for files having a size greater than a segment size andreferences for logical files containing a number of embedded files,where reference provide access to the respective file distributed overstorage nodes.

Point 18. The method of point 1, further comprising arranging temporarystorage of file data within a local cache by:

operating over compound blocks of data;

dividing memory space into regions with compound blocks of equal size;

employing a file structure to optimize file arrangement within the localcache; and

performing garbage collection to arrange free compound blocks.

Point 19. The method of point 18, wherein contiguous small blocks ofdata are combined into large compound blocks, where small blockscorrespond to a block-based file system, and compound blocks correspondto an object-based file system.

Point 20. The method of point 18, wherein cache memory includes aplurality of regions, and further wherein each region comprises a numberof compound blocks, wherein compound blocks are of the same size atleast within each region.

Point 21. The method of point 18, wherein arranging temporary storage offile data within a local cache further includes cache optimizationemploying information representing a file structure.

Point 22. The method of point 21 wherein cache optimization issimplified by classifying files depending on respective access patternsinto several categories, and employing the same cache managementstrategy for files of the same category.

Point 23. The method of point 18, wherein garbage collector releasesless significant compound blocks, where significance estimates areobtained from time of the last access and a data access pattern.

Point 24. The method of point 1, wherein a method of file data retrievalfrom remote storage nodes, the method comprising:

accessing, by at least one processor configured to execute code storedin non-transitory processor readable media, file metadata referenceswithin a local cache or within remote storage nodes;

receiving, by the at least one processor, a plurality of packagescontaining file metadata from remote storage nodes, where the packagesare requested in advance by metadata references;

receiving, by the at least one processor, a plurality of other packagescontaining encoded file segments from storage nodes, where the packagesare requested in advance by data references, where data references areobtained as a part of file metadata;

reconstructing, by the at least one processor, file data from thepackages as a function of metadata that represents parameters ofencoding scheme and file splitting scheme.

Point 25. The method of point 24, wherein file retrieval speed isenhanced by caching metadata from a plurality of files on the clientside.

Point 26. The method of claim 9, wherein method for erasure coding,comprising:

executing, by at least one processor configured to execute code storedin non-transitory processor readable media, data encoding with anerror-correction code C to produce N codeword chunks, wherein theerror-correction code C of length N=tn is based on 2 h component codes:h outer codes of lengths b_(i)n, 0≤i<h, and h inner codes of length t;

distributing, by the at least one processor, N codeword chunks over aset of storage nodes, wherein mapping of codeword chunks to storagenodes is optimized to balance network load among storage nodes;

executing, by the at least one processor, reconstruction of data chunksfrom codeword chunks, wherein codeword chunks are requested from storagenodes on demand and the number of required codeword chunks is minimized;and

executing, by the at least one processor, data repair, wherein erasedcodeword chunks are reconstructed from other codeword chunks, andfurther wherein a number of requests to storage nodes for codewordchunks is minimized.

Point 27. The method of point 26, wherein dimensions of outer codes andlength multipliers b_(i) are selected to maximize minimum distance ofcode C.

Point 28. The method of point 26, wherein data is partitioned into Kinformation chunks prior to encoding, and encoding is implemented asmultiplication of vectors consisting of K elements of information chunksby K×N generator matrix of code C, wherein the generator matrixcomprises K×K sparse matrix, such that its inverse matrix is alsosparse.

Point 29. The method of point 28, wherein K×N generator matrix of code Ccomprises a matrix obtained by column and row permutations from the K×Kblock-diagonal matrix.

Point 30. The method of point 28, wherein K×N generator matrix of code Ccomprises K×K block-diagonal matrix.

Point 31. The method of point 26, wherein a codeword of code C comprisesn groups of t elements, and further wherein any single erased codewordchunk within a group may be repaired as linear combination of other t−1chunks of the same group.

Point 32. The method of point 26, wherein erased codeword chunk arereconstructed by multi-stage decoding, and further wherein each decodingstage comprises decoding in one inner code and one outer code, wherecorrection capability of employed inner codes increase with stage indexand stages are terminated upon recovering of all erasures within thecodeword.

Point 33. The method of point 32, wherein an inner code in eachsubsequent stage has higher minimum distance, than an inner codeemployed in previous stage.

Point 34. The method of point 26, wherein dimensions of outer codesk_(i) divided by respective length multipliers b_(i) constitutenon-decreasing sequence, that is k₀/b₀≤k₁/b₁≤ . . . ≤k_(h−1)/b_(h−1).

Point 35. The method of point 34, wherein outer codes are a maximumdistance separable codes, e.g., Reed-Solomon codes.

Point 36. The method of point 26, wherein inner codes are nested codesof the same length and with maximized minimum distances.

Point 37. The method of point 36, wherein inner codes are a maximumdistance separable codes, e.g., Reed-Solomon codes.

Point 38. The method of point 36 and 34, wherein inner codes are binarylinear block codes with maximum possible minimum distances w_(i) andlength multipliers b_(i) are such that w₀<w₁< . . . <w_(h−1).

Point 39. The method of point 26 and 29 or 30, wherein updating ofseveral information chunks, corresponding to the same sxs submatrix ofthe block-diagonal matrix, results in no more than N−K+s updatedcodeword chunks, where N is the length and K is the dimension ofemployed error-correction code.

Point 40. The method of point 26 and 29 or 30, wherein retrieval ofseveral information chunks, corresponding to the same s×s submatrix ofthe block-diagonal matrix requires s codeword chunks to be downloadedfrom storage nodes.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges can be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

1-18. (canceled)
 19. A method of data retrieval from remote storagenodes, the method comprising: accessing, by one or more processorsconfigured to execute code stored in non-transitory processor readablemedia, file metadata references within a local cache or within remotestorage nodes; receiving, by the one or more processors, a plurality ofpackages from remote storage nodes by metadata references, each of thepackages contain file metadata; receiving, by the one or moreprocessors, a plurality of other packages containing encoded filesegments from storage nodes by data references, wherein the encoded filesegments are obtained at least partly from file metadata;reconstructing, by the one or more processors, file data from thepackages as a function of metadata representing parameters associatedwith an encoding scheme and file splitting scheme.
 20. The method ofclaim 19, wherein file retrieval speed is enhanced by caching metadatafrom a plurality of client side files. 21-40. (canceled)
 41. A systemfor data retrieval from remote storage nodes, the system comprising: oneor more processors in electronic communication with non-transitoryprocessor readable storage media; and one or more software modulescomprising executable instructions stored in the storage media, whereinthe one or more software modules are executable by the one or moreprocessors that, when so executed, cause the one or more processors to:access, by one or more processors, file metadata references within alocal cache or within remote storage nodes; receive, by the one or moreprocessors, a plurality of packages from remote storage nodes bymetadata references, each of the packages contain file metadata;receive, by the one or more processors, a plurality of other packagescontaining encoded file segments from storage nodes by data references,wherein the encoded file segments are obtained at least partly from filemetadata; and reconstruct, by the one or more processors, file data fromthe packages as a function of metadata representing parametersassociated with an encoding scheme and file splitting scheme.
 42. Thesystem of claim 41, wherein file retrieval speed is enhanced by cachingmetadata from a plurality of client side files.